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?
On Mon, Jul 11, 2016 at 9:45 AM, Thomas Broyer <t.broyer@gmail.com> wrote:
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.
Regards,
Paul Mazzuca
Founder and CEO
Recent Software
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