If a single page application has control on the server side, it is posible to implement the authorization process like a regular web application does, using Authorization Code Grant, instead of the Implicit Code Grant used by SPAs . That is, send the server the order to authorize and let him start the authorization with Auth0 using the client secret securely stored in the backend . So we have an SPA application (like Angular) with just a traditional web app flow used for authentication. This has the advantage of being more secure than Implicit Code Grant used by SPAs and having more functions available, like using refresh tokens.
I’m considering this approach but don’t know if there is any drawback in implementing the Authorization Code Grant in SPAs as explained above, instead of the recommended Implicit Grant Flow. I’m missing something?
The big difference is that using your flow, the SPA wouldn’t have any way of knowing if the user is logged in and who the user is, until the backend is called. Other than that, I don’t really think there’s a big difference. For what it’s worth: the Auth0 Dashboard also uses your flow (as far as I can tell).
I believe your proposed flow is even considered to be slightly more secure, but don’t quote me on that. Both flows have their unique security considerations: the recommended flow is vulnerable to someone stealing the access token through JavaScript, the other one needs CSRF protection. Pick your poison
IIUC, the relevant RFC recommends using the authorization code grant over the implicit grant whenever possible:
Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, such as those described in Sections 10.3 and 10.16, especially when the authorization code grant type is available. RFC 6749 - The OAuth 2.0 Authorization Framework
And goes even further to recommend the PKCE extension to the authorization code grant:
OAuth 2.0 public clients utilizing the Authorization Code Grant are
susceptible to the authorization code interception attack. This
specification describes the attack as well as a technique to mitigate
against the threat through the use of Proof Key for Code Exchange
(PKCE, pronounced “pixy”). RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients
So generally speaking I share the opinion of @david.casillas, but still not sure why the recommended flows by Auth0 are as they are.
I hope that someone from Auth0’s team would weigh in on this…
Hi @arik_auth0! We are, in fact, in the midst of updating our guidance and SDKs on the topic of implicit grant vs. authorization code grant with PKCE for use in SPAs. As @markd cited in his comment, an article has been published by our Principal Architect @Vittorio on this topic already, and we’ll be coming out with some news around official support in our JavaScript solutions soon. Please be aware we’ve been very actively working on this!
