9

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?

  • I am sticking to implicit. I agree with you about which one is more risky... – Tiago Coelho Dec 7 '18 at 23:35
1

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.

  • Thanks for the update. However, if the RT is not returned (as allowable), would that not imply that every time a new AT is required, the full auth code must be performed? I cannot imagine that being particularly efficient. – Eric B. Jan 16 at 21:10
  • @EricB. yes its less effcient, but its not a big deal in practice. Refresh tokens are intended for "offline access", i.e. background actions that happen when the user is not present. – Justin Jan 16 at 23:09
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:

  • PKCE is great for exchanging access tokens and refresh tokens but the concern remains having the refresh tokens in the browser which I still don't know if is safe or not. But I suppose if only the AT is exchanged then it would be ok. – Eric B. Jan 17 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.