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?
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 TokensJWT 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.- Added support for CordovaDo 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 supportIf 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 supportWhat would be nice:- To make sure it is truly secure and robust through your contributions and discussionImplicit 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.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.--
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-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment