Hi all, Am 09.11.18 um 21:22 schrieb Brock Allen: > > Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get > into specifics, but many of the points seem confused (or at least > confuse me) and/or the conclusion that code flow is the only approach > seems misleading. For example: > > "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is > required according to Section 6), so clients and authorization servers > MUST NOT use the Implicit Flow for browser-based apps." > > This is specious. The threat is the token is in the URL, not that > implicit clients can't use PKCE. So perhaps the document should > explain the variety of mitigations, not just one? While code flow is > one, using CSP and the browser history API to remove the token from > the URL is another. Elsewhere in the document the use of CSP is a > "SHOULD". That's great, but using CSP can be and is used today, and > doesn't necessitate code flow.
Could you please expand on what you are achieving with replacing the URL using the history API? Removing the token from the browser's history, or any protection beyond that? > > "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." > > As offered by someone else already, this is opinion and not objective. > IMO, this diminishes the potential of this document. Another aspect is that removing implicit as an option greatly simplifies security analysis and formal proofs of security (of which I hope we will see more instances in the future). If you look at it this way, it is much more than an opinion and it is definitely objective. - Daniel
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
