We've taken a similar approach for SMART Health IT [1], using the code flow for public clients to support in-browser apps, and <1h token lifetime. (We also allow these public clients to request a limited-duration refresh token by asking for an "online_access" scope; these refresh tokens stop working when the user's session with the AS ends — useful in systems where that session concept is meaningful.)
-Josh 1. http://docs.smarthealthit.org/authorization/ On Thu, Feb 16, 2017 at 6:13 PM, Bill Burke <bbu...@redhat.com> wrote: > For our IDP [1], our javascript library uses the auth code flow, but > requires a public client, redirect_uri validation, and also does CORS > checks and processing. We did not like Implicit Flow because > > 1) access tokens would be in the browser history > > 2) short lived access tokens (seconds or minutes) would require a browser > redirect > > I'd be really curious to hear other's thoughts though. > > [1] http://keycloak.org > > > > > On 2/16/17 5:44 PM, Jim Manico wrote: > > Hello Folks, > > I noticed that Google supports the OAuth 2 Implicit flow for third-party > JavaScript applications. > > https://developers.google.com/identity/protocols/OAuth2UserAgent > > Isn't this generally discouraged from a security POV? *Is there a better > OAuth 2 flow for third party SPA applications?* > Aloha, > > -- > Jim Manico > Manicode Securityhttps://www.manicode.com > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
