Should an SPA use OIDC's Implicit flow or Auth Code flow?

Question

We are developing a new Angular SPA which leverages Keycloak for its SSO abilities using OpenID Connect (OIDC). The app is currently designed to use the Implicit flow to retrieve short-lived access tokens via the keycloak JS adapter.

However, recently, I've been seeing some emails in the ietf mailing list indicating that Auth code flow should be preferred over implicit flow due to security issues of having access tokens show up in browser history and/or log files (if any SSL termination/inspection is in place/etc).

I understand the security concerns with having an AT show up anywhere in a log file. I do not, however, understand how the Auth Code flow can be considered as more secure, or why it should be preferred over Implicit flow. Isn't having the Refresh Token in the browser/SPA a higher security risk than having a short-lived AT in a log file?

What is the preferred mechanism to use today for an SPA? Is there a recommended approach?

Answer 1

Nowadays the recommended approach is to use Authorization Code with PKCE (Proof Key for Code Exchange).

The threat to be concerned about is leaking the access token from the URL - the URL is not a good place to put sensitive information and there are a number of ways that the URL could be leaked. When a confidential client uses code flow a leak of the authorization code from the URL is no big deal as an attacker cannot use the authorization code without knowing the client secret, however with a public client the attacker knows the client secret and so the token exchange step offers little protection. Implicit flow mitigates this by putting the access token into the hash fragment which is not sent web servers as part of the request, making it more secure than using code flow without PKCE. Also its worth noting that at the time that OIDC was designed CORS was not as widely supported and so using code flow in a SPA presented some challenges even without the security concerns, which I think goes some way towards explaining why Implicit flow was included in the original OIDC spec.

PKCE works by generating a random string (called a code verifier) for each authentication attempt, and then uses "some cryptography" to ensure that only callers who know this random string can complete the token exchange making the authorization code useless even to attackers that know the client secret.

References:

• https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/
• https://christianlydemann.com/implicit-flow-vs-code-flow-with-pkce/

Answer 2

Nice research effort from the OP! Upvoted. So you have already got an answer from your cross-posted question in SO. On top of that, here I'm just trying to clarify on the one statement in your question, based on the original OAuth2 RFC 6749.

I understand the security concerns with having an AT show up anywhere in a log file. I do not, however, understand how the Auth Code flow can be considered as more secure, or why it should be preferred over Implicit flow. Isn't having the Refresh Token in the browser/SPA a higher security risk than having a short-lived AT in a log file?

• Technically, the Auth Code flow does not necessarily mean a Refresh Token (RT) will always return. Per OAuth2 RFC section 4.1.4, an RT in response is optional. Client could choose to not requesting it, and/or the server could choose to not issue it.

• The concern of Implicit Grant is not just the logging. OAuth2 RFC section 4.2 mentions:

  Because (in Implicit Grant) the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.

  The Auth Code grant, on the contrary, does not have this concern. The redemption of auth code and the tokens happens between the SPA and the auth server, which typically won't leave a trace in the normal browser history.