Thanks for putting this together Aaron. Having read through the document, I am not as convinced that there is enough of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.
In section 7.8. the document outlines the Implicit flow disadvantages as following: "- OAuth 2.0 provides no mechanism for a client to verify that an access token was issued to it, which could lead to misuse and possible impersonation attacks if a malicious party hands off an access token it retrieved through some other means to the client." If you use Code + PKCE with no client secret (public client) as it is being advocated, you can't verify the client either. PKCE is not for authenticating the client, it is there to provide a mechanism to verify inter-app communication, which occurs between a browser and a native app. There is no inter-app communication in implicit (everything stays in the browser), so no need for PKCE. "- Supporting the implicit flow requires additional code, more upkeep and understanding of the related security considerations, while limiting the authorization server to just the authorization code flow simplifies the implementation." This is subjective and can be easily argued the other way. I think one of the main selling points behind implicit was its simplicity. It is hard to argue (putting libraries aside) that making one redirect (implicit) requires more code, work, etc.. than making a redirect and at least two additional calls in order to get AT (plus CORS on AS side). Further, in the beginning paragraph of 7.8, you mention that implicit gets the AT through the front-channel. Exchanging code for AT will also happen in the browser , where instead of a url you will have an xhr (and again, now we have cors) Finally, how is the AT going to be refreshed? Are we allowing for long lived RT in the browser? I see that the document mentions CSP in 7.7, but doesn't the same apply to securing AT with Implicit? Regrads, Tomek Stojecki On Tuesday, November 6, 2018, 10:55:40 AM GMT+1, Hannes Tschofenig <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 https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
