Hi Aaron, Thanks for writing up clear guidelines for SPAs. I reviewed the draft and would like to offer some feedback:
One important aspect I am missing is a brief discussion on how, in general, SPAs should be implemented; in particular, whether the browser-app exchanges the code for an access token or whether the server does that. In Section 7.6 it becomes clear that you propose to use the first solution (do everything in the browser, as would be expected from a true in-browser app). Other remarks: 6.1.: "The PKCE extension prevents an attack where the authorization code is intercepted and exchanged for an access token by a malicious client" I guess what you want to say here is that PKCE prevents the injection of an *authorization code* by a *malicious user*, right? 6.2.: "If an authorization server wishes to provide some flexibility in redirect URI usage to clients, it MAY require that only the hostname component of the redirect URI match the hostname of the URL the application is served from." At the bare minimum, the whole origin should be an exact match (otherwise a network attacker can intercept the auth code in the authz response when he uses the redirect URI http://correct-hostname.example ). This is also further discussed here: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-08#section-3.1 We there recommend exact redirect URI matching only. And finally some nitpicking: 5. "For example, an web email client" (an -> a) "or use the OAuth Password grant" -> should be the "Resource Owner Password Credentials Grant" to stick to the RFC6749 terminology - Daniel Am 06.11.18 um 11:13 schrieb Aaron Parecki: > Thanks Hannes, > > Since I wasn't able to give an intro during the meeting today, I'd > like to share a little more context about this here as well. > > At the Internet Identity Workshop in Mountain View last week, I led a > session to collect feedback on recommendations for OAuth for browser > based apps. During the session, we came up with a list of several > points based on the collective experience of the attendees. I then > tried to address all those points in this draft. > > The goal of this is not to specify any new behavior, but rather to > limit the possibilities that the existing OAuth specs provide, to > ensure a secure implementation in browser based apps. > > Thanks in advance for your review and feedback! > > Aaron Parecki > aaronpk.com <http://aaronpk.com> > > > > On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig > <hannes.tschofe...@arm.com <mailto:hannes.tschofe...@arm.com>> wrote: > > Hi all, > > Today we were not able to talk about > draft-parecki-oauth-browser-based-apps-00, which describes "OAuth > 2.0 for Browser-Based Apps". > > Aaron put a few slides together, which can be found here: > > https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf > > Your review of this new draft is highly appreciated. > > Ciao > Hannes > 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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > -- > ---- > Aaron Parecki > aaronparecki.com <http://aaronparecki.com> > @aaronpk <http://twitter.com/aaronpk> > > > _______________________________________________ > 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
