+1. I think this would be good to have. Phil
> On May 17, 2018, at 9:23 AM, Hannes Tschofenig <hannes.tschofe...@arm.com> > wrote: > > Hi Brock, > > there have been several attempts to start writing some guidance but so far we > haven’t gotten too far. > IMHO it would be great to have a document. > > Ciao > Hannes > > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brock Allen > Sent: 17 May 2018 14:57 > To: oauth@ietf.org > Subject: [OAUTH-WG] is updated guidance needed for JS/SPA apps? > > Much like updated guidance was provided with the "OAuth2 for native apps" > RFC, should there be one for "browser-based client-side JS apps"? I ask > because google is actively discouraging the use of implicit flow: > > https://github.com/openid/AppAuth-JS/issues/59#issuecomment-389639290 > > From what I can tell, the complaints with implicit are: > * access token in URL > * access token in browser history > * iframe complexity when using prompt=none to "refresh" access tokens > > But this requires: > * AS/OP to support PKCE > * AS/OP to support CORS > * user-agent must support CORS > * AS/OP to maintain short-lived refresh tokens > * AS/OP must aggressively revoke refresh tokens at user signout (which is not > something OAuth2 "knows" about) > * if the above point can't work, then client must proactively use revocation > endpoint if/when user triggers logout > > Any use in discussing this? > > -Brock > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > 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