GWT OAuth2 Open Source Release

[Paul Mazzuca]

I thought that it might be a good idea to update the existing GWT-OAuth2 project from 2011.  I know that I have certainly needed a reliable framework for just about all of my projects, and unfortunately the old one is too out of date for my use cases.   Let me know what you think and contributions are definitely welcome.  Ideally, with the help of the community, we can create a truly robust GWT module. 

Just to give you a quick summary, I have done the following:

- Added authorization code flow with refresh tokens and JSON Web Tokens

- Added support for Cordova

- Hopefully made it a little easier to navigate

- Started to implement JsInterop 

- Google Provider support

- Some Facebook provider support

What would be nice:

- To make sure it is truly secure and robust through your contributions and discussion

https://github.com/Koozamo/ezgwt-oauth

[Gilberto]

Looks amazing Paul!

Do you have interest in building a template/example project, covering all the common auth scenarios, in partnership with GWT Material?

I talked with Mark Kevin (the founder of GWT Material) about it and I think we could make an interesting starter project for the community.

I also would like to test it with gwt-views ;-)


Cheers,

Gilberto

[Thomas Broyer]

There are many many many small things that are either wrong, or inappropriate, or inappropriately described.

On Thursday, July 7, 2016 at 1:22:55 AM UTC+2, Paul Mazzuca wrote:

I thought that it might be a good idea to update the existing GWT-OAuth2 project from 2011.  I know that I have certainly needed a reliable framework for just about all of my projects, and unfortunately the old one is too out of date for my use cases.   Let me know what you think and contributions are definitely welcome.  Ideally, with the help of the community, we can create a truly robust GWT module. 

Just to give you a quick summary, I have done the following:

- Added authorization code flow with refresh tokens and JSON Web Tokens

JWT is a "format". What you're actually talking about is ID Tokens.

ID Tokens, contrary to all other OAuth tokens and codes, and not opaque. They serve (almost) no other goal than authenticating the user (whereas OAuth is about authorization).

ID Tokens come from OpenID Connect, which adds authentication on top of OAuth 2.

See also http://oauth.net/articles/authentication/

 

- Added support for Cordova

Do not use WebViews for authentication or authorization, use true "in-app browsers" (aka Chrome Custom Tabs on Android, and SFSafariViewController on iOS) and fallback to true browsers, but do not use WebViews.

See https://tools.ietf.org/html/draft-ietf-oauth-native-apps for the rationale.

 

- Hopefully made it a little easier to navigate

- Started to implement JsInterop 

- Google Provider support

If you intend to use this as authentication (generally, when accessing the user's profile info, one wants authentication, not just authorization), then use OpenID Connect.

 

- Some Facebook provider support

What would be nice:

- To make sure it is truly secure and robust through your contributions and discussion

Implicit Flow is meant specifically for cases where there's no server. It's inherently less secure than the Authorization Code Flow.

If you have a server component (that does more than just serving static assets), then use the Authorization Code Flow, and do not by any mean share the tokens with the JS client.

See https://mailarchive.ietf.org/arch/msg/oauth/CI7xu-5u8O6VTeArl5gLvg2QzNE

In your "security considerations" in your readme, you seem to mix up your client and server components, and possibly misunderstand the documents you're linking too.

Your client_secret should be kept as secret as possible (sic!), so it must not appear in your client app; the authorization code flow is meant to be done by a server component (servlet, whatever).

If it does (as is likely the case with Cordova, or any type of "installed/native app"), then the client_secret is not really a secret, and the app should not be viewed as a "private client" (in OAuth parlance). So care should be taken to not grant too much access to such apps (just like for the Implicit Flow, which doesn't even require a client_secret).

The Google documentation you're linking to is specifically about "server-side web apps" (you'll notice that toe doc about "javascript web apps" describes the Implicit Flow)

See also http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20151116/005865.html (which is what I believe Google is using for their "Login with Google" button)

All in all, the hardest part about such libraries is to come up with a good API. For now, I preferred rewriting my implementations (both RPs and IdPs) from scratch each time, because while things were similar (and my needs were very similar, which will not be the case of users of such libraries), they weren't identical, and trying to build a reusable library with configurable parts would have considerably increased complexity and wouldn't have been worth it. YMMV.

[Paul Mazzuca]

Thanks Gilberto.  I think that's a great idea, however I would like to get more feedback and have an opportunity to address key issues first, especially in regards to Thomas Boyer's recent comments.   Once we get through those issues and updates, definitely.  GWT Material is a fantastic project by the way.  

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/I4gXb4QLWtQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Paul Mazzuca

Founder and CEO

Recent Software

      

[Paul Mazzuca]

Thomas, thanks for all the feedback, and thanks again for taking the time.  This is exactly what we were hoping for.  We will need some time to read through the references you have provided. Once we get through them, I will be sure to respond back in the forum. 

A couple of points that I think I can respond to right now though...

As far as writing an implementation from scratch, though I see the reasoning behind it, especially given the complexity of authentication/authorization, I still see value in at least in *trying* to build a library for the same reasons why developers build libraries in the first place.  Just as errors can arise in trying to make a complex protocol expressed in a simple API, so do errors arise when trying to rewrite from scratch each time.  

In regards to the security considerations, is there an issue with not viewing your App as a "private client" as you say?  Why not just consider the client_secret as not that secret?  Native Apps seem to do it all the time and Google suggests that flow for Native Apps in its docs?  

--

You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/I4gXb4QLWtQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Paul Mazzuca]

After reading some of the docs further, I think some of the confusion stemmed from how Google describes that an Installed App can execute a Authorization Code Flow (https://developers.google.com/identity/protocols/OAuth2).  

In this case, the doc suggests that the  “process results in a client ID and, in some cases, a client secret, which you embed in the source code of your application. (In this context, the client secret is obviously not treated as a secret.)…The application should store the refresh token for future use and use the access token to access a Google API. Once the access token expires, the application uses the refresh token to obtain a new one.”  

One could draw many similarities between a GWT app and native app.  The question I have is why is a native App allowed to store this “sensitive” data and not a GWT application. 

Are we presuming that a binary, which can be decompiled and is in the user’s control,  provides such a greater amount of security of secrets over HTML 5 web storage that it is okay to store sensitive tokens in a native app but not in a GWT app, especially when it just takes one curious user to find the same client_secret stored in all other native app installs?

On Mon, Jul 11, 2016 at 9:45 AM, Thomas Broyer <t.br...@gmail.com> wrote:

--

You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/I4gXb4QLWtQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

It amounts to knowledge by the AS whether this is a confidential or public client. When registering a native app, Google knows that it can only be a public app. When registering a web app, they can assume this will be a confidential client and expect you to keep the secret, well, secret. The AS (Google) can then have different policies regarding what scopes they allow, or how they present the consent screen and admin panel, depending on the type of client.

Have a look at the definition of both types of clients in RFC 6749.

[Paul Mazzuca]

You are correct. The RFC makes the distinction that "dynamically issued credentials such as access tokens or refresh tokens can received an acceptable level of protection" in a native application.  However, the lines certainly can be blurred with a Cordova App which is both a user agent based application and a native application. 

I guess the question still remains, what is the GWT recommended flow for performing OAuth if it is desired to keep a user logged in beyond the expiration of an access token?

On Tue, Jul 12, 2016 at 9:55 AM, Thomas Broyer <t.br...@gmail.com> wrote:

It amounts to knowledge by the AS whether this is a confidential or public client. When registering a native app, Google knows that it can only be a public app. When registering a web app, they can assume this will be a confidential client and expect you to keep the secret, well, secret. The AS (Google) can then have different policies regarding what scopes they allow, or how they present the consent screen and admin panel, depending on the type of client.

Have a look at the definition of both types of clients in RFC 6749.

--
You received this message because you are subscribed to a topic in the Google Groups "GWT Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/I4gXb4QLWtQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.