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.
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.