OAuth 2 Token Introspection

🔥More exclusive content: https://productioncoder.com/you-decid...
Twitter:   / _jgoebel  
Website: https://jangoebel.com
Blog: https://productioncoder.com
Token Introspection RFC: https://datatracker.ietf.org/doc/html...

00:00 What is OAuth 2 Token Introspection?
01:05 Types of access tokens in OAuth
01:54 OAuth Token Introspection with opaque access tokens
03:39 Token Metadata returned by OAuth authorization server
04:45 OAuth Token Introspection with structured access tokens (e.g. JWTs)
07:02 Propagation Delays in OAuth deployments

With token introspection, the OAuth2 or OpenID Connect server offers a dedicated endpoint where clients can send tokens to and receive all relevant metadata for the respective token in return. The metadata contains whether the token is active or not, what scope the token contains and many more additional details.

In case the authorization server is using opaque tokens, the token endpoint is essential to gather information about a presented access token - i.e. to assess whether the token is valid at all and what actions the client that presented the token is allowed to do.

Even though resource servers can perform token validation locally when using structured tokens like JWTs, the OAuth token introspection endpoint can still be of value. If a token is revoked via the OAuth token revocation endpoint, the protected resource would know if it were to call the token introspection endpoint. However if the protected resource is only validating the token locally then it would still grant access to the entity that presented the token even though the token might have already been revoked.

Therefore, at least a hybrid approach seems reasonable. For critical actions, the token should be sent to the token introspection endpoint. Or - even better - force the user to login again and request additional scopes (e.g. if you want to buys something in an online shop) before you actually execute the transaction.