Id Tokens and User Authentication

Background

Previously we discussed Logout and discovered that it may only work if we received an Id Token during Login.

Requesting an Id Token during Login

In the Final SPA Code Sample we will update to use the recommended Open Id Connect flow:

  • response_type = token id_token

The Id Token is an extra JWT returned in the response. This token is private to our UI and is not used by APIs:

The Id Token may also contain Basic User Info but, as we’ve discussed, the UI may also need to call its API to get more detailed User Data.

Token Validation

Before accepting tokens on its redirect URI, OIDC Client fully validates the id token and checks that it was issued for this SPA. The access token is not read, but its hash is checked against the at_hash value.

Users are now Authenticated

We can now make this statement, since the id token is Proof of the User Authentication Event to our particular SPA, based on cryptographic verification.

Logout now Works

When we now do an Open Id Connect logout, the OIDC Client sends the id token in the URL and Okta will accept the request and remove session cookies:

Attackers and the Redirect URI

The above validation mechanism ensures that the UI only uses access tokens issued to itself. This gives us extra protection against token substitution attacks:

I’m not convinced that the above is a major issue for most Corporate Apps, but it feels right that our UI validates received tokens.

Security Reviews and PEN Tests

In some corporate sectors you will also need to think about third party perceptions. If our app is missing Open Id Connect security features it is likely to be flagged as having vulnerabilities.

SPA Code Complexity

The one downside of using id tokens in an SPA is extra complexity, where we require the ‘jsrsasign’ library to do cryptographic token validation. 

At least we are not writing the code ourselves though – we have externalized it to a Respected 3rd Party Library written by Security Experts.

Other Security Libraries and Id Tokens

As you can probably tell, in my early usage of OIDC Client, I was considering avoiding id tokens, due to the above complexity.

Partly this is because I have used Google AppAuth Mobile libraries in the past, and they do not fully support id token validation at the time of writing:

Use of id tokens in the mobile case is a little less important though, because token substitution attacks are mitigated via PKCE handling, which we will look at in a later post.

Where Are We?

We can now say that our SPA authenticates its users and we have some extra security features.

There is more complexity in the browser code, and the Javascript download size is greater, but these do not feel like blocking issues.

Next Steps