Update "Which OAuth 2.0 Grant should I use?" to reflect current SPA recommendations

[dmark]

The Which OAuth 2.0 Grant should I use? page needs to be updated to reflect the current recommendations for SPA (Auth Code + PKCE vs. Implicit Grant).

Ref:

• https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-02
• https://auth0.com/blog/oauth2-implicit-grant-and-spa/

[fnlctrl]

The document is probably not suitable for reference according to the section

Status of This Memo

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

I just happened to find this document, and after reading it filled me with questions. Since there doesn't seem to be any open discussions for it I'll just leave them here. I'm no expert of OAuth so these questions may be invalid.

1. The document recommends browser-based applications to switch to authentication code flow, instead of using implicit flow. Does this imply that these applications would require user to authorize every time they use the app?

   • As a pure browser-based application with not backend part are not allowed to store client_secret and refresh_token, switching to code flow would require getting a new code every time, which is the equivalent of authorizing every time.
   • Implicit grant is the only way to let users authorize once and continue to use the application until the cookie provided by the authorization endpoint expires.

2. Doesn't using HTTPS + Same origin everywhere (web app host, script host, redirect_uri) avoid most disadvantages/threats proposed by the document (Expect "9.8.2. Threat: Access Token Leak in Browser History" and "9.8.4. Threat: Access Token Leak to Third Party Scripts")? Also, all threats documented in RFC6819 Section 4.4.2 have valid countermeasures.

   • redirect_url using HTTPS prevents eavesdropping (9.8.1)
   • HTTPS authenticates client and authorization server's identity and prevents malicious content (9.8.3)
   • Authorization servers store and check pre-registered valid client origins
   • For 9.8.4, developers can deploy another page for redirect_url that is opened in a popup (e.g. https://foo.com/oauth_redirect) with no 3rd party script. The popup page contains only script to postMessage access token back to main window (with targetOrigin "foo.com") so that 3rd party script cannot read the access token.

[dmark]

I can understand not wanting to put not-yet-approved standards stuff into the docs. I do feel like the docs should at least mention the existence of the draft recommendation. Just my opinion but anyone building solution on OAuth/OIDC should be aware of what is coming.

I'm no expert, so I'll defer to the OAuth and OIDC working group folks. Your questions sound reasonable to me, but I'm assuming there are good reasons for these proposals.

[alecor191]

I stumbled on this issue as I was wondering the same: Besides the document referenced by dmark, I noticed the following:

IETF OAuth 2.0 Security Best Current Practice

In order to avoid these issues, clients SHOULD NOT use the implicit
grant (response type "token") or any other response type issuing
access tokens in the authorization response, such as "token id_token"
and "code token id_token", unless the issued access tokens are
sender-constrained and access token injection in the authorization
response is prevented.

While also just a draft, note that this one seems to be actively being worked on (12 iterations, latest draft version valid until September 2019).

Official OAuth documentation on oauth.net

It is generally not recommended to use the implicit flow (and some 
servers prohibit this flow entirely).
In the time since the spec was originally written, the industry best 
practice has changed to recommend that public clients should use 
the authorization code flow with the PKCE extension instead.

Is Auth0 still recommending "implicit flow" for SPAs as described in Auth0's Which OAuth 2.0 Grant should I use? guidance page?