The Three Most Common OAuth Implementation Mistakes
Implementing OAuth. That’s something any developer can do.
There are plenty of examples and YouTube instructional guides out there. However, many (if not most) of them demonstrate some fundamental mistakes.
Here’s what’s wrong with most OAuth implementations:
1. Disabled Issuer And Audience Checks
By far the most common implementation mistake is not validating the issuer and audience claims.
Issuer and audience settings can be frustrating. When bootstrapping OAuth in an application, these two settings often cause the most issues. So, the easiest way to “make it work” is by simply disabling them.
However, it’s important to understand what these claims mean:
- The issuer claim specifies who issued the OAuth token. In other words, where the token came from.
- The audience claim specifies who the token is intended for.
By disabling issuer and audience validation, you’re essentially saying: “I’ll trust any token as long as the signature checks out.”
By doing so, you remove the ability of the authorization server to control which applications can access what. Even worse, you might end up accepting tokens that were never intended for your application in the first place.
2. Using The Email-Address As A Primary Identifier
When a user authenticates via OAuth, their identity is represented by a token. This token contains a set of claims: pieces of information about the user.
One commonly included claim is the email
claim, which contains the user's email address. However, this is often accompanied by another claim: email_verified
. It highlights an important issue: the email address in the token may be arbitrary if it hasn't been verified.
More importantly, the token includes a claim called sub
. This claim provides a unique, stable identifier for the user, one that is consistent across sessions and does not change, even if the user updates their email address.
For this reason, the sub
claim should be used as the primary identifier for authenticated users, rather than relying on the email
claim.
Do note that uniqueness of the sub claim is not guaranteed across different Identity Providers, that’s why it’s recommended to persist both the value of the sub
claim and the iss
(or the Identity Provider).
3. Not Signing Out Correctly
A common misconception is that authentication with OAuth is represented solely by a token and that this token constitutes the user session.
In most cases, an OAuth server also acts as a Single Sign-On (SSO) server. Consequently, authentication also manifests as an HTTP session (typically backed by a cookie) at the OAuth server.
Signing into the OAuth server, and thereby initiating the HTTP session, is part of the OAuth flow used to obtain a token. So, after completing the flow, the user ends up with two things:
- An active HTTP session at the Single Sign-On server
- One or several tokens (e.g., access token, ID token, refresh token)
Therefore, signing out properly requires two steps:
- Revoking the tokens
- Ending the HTTP session
In practice, however, only one of these steps is often performed — typically, only the tokens are revoked. This means that if someone has access to the browser, they can easily trigger the sign-in flow again and be automatically logged back in via the still-active SSO session.
TLDR
Anyone can implement OAuth. But enabling users to authenticate is only half the job. The other half is keeping everyone else out.
Setting up proper authentication and authorization requires validating a number of things:
- Validate the audience
- Validate the issuer
- Validate the token signature
- Validate the NBF and the EXP claim
- Validate the token hasn’t been revoked
Source: https://www.entrypage.io/wiki/oidc/validating-json-web-tokens