Token Revocation & Introspection

Imagine you've logged into an app, and it gives you a digital key (an access token) to open certain doors (access resources). What if you want to change the lock, or lose the key?

This lesson explores how to manage these digital keys: revoking them to stop access, and introspecting them to check if they're still valid.

Token revocation is the process of explicitly invalidating an access or refresh token before its natural expiration time.

• Why revoke? User logs out, password reset, account compromise, or the client application is no longer trusted.
• It immediately cuts off access, enhancing security.

OAuth2 and OpenID Connect providers offer a standard revocation endpoint. Clients send a POST request to this endpoint to invalidate a token.

This endpoint requires client authentication to ensure only authorized clients can revoke tokens.

To revoke an access token, the client sends the token to the revocation endpoint. The server then marks the token as invalid.

Here's a conceptual example using curl. Remember, this is an API call, not a runnable local program:

Revoking a refresh token is crucial! Since a refresh token can be used to obtain *new* access tokens, revoking it prevents future access.

Often, revoking a refresh token also implicitly revokes all access tokens that were issued using it.

Token introspection is the process where a resource server can query the authorization server to determine the active status and metadata of a given token.

• This is especially useful for opaque tokens (tokens that don't reveal their contents), where the resource server can't validate them locally.
• It answers: "Is this token still good?"

Similar to revocation, OAuth2 and OIDC providers expose an introspection endpoint. Resource servers (or other authorized parties) use this endpoint.

The endpoint typically requires authentication, ensuring only trusted entities can inspect tokens.

When a resource server receives an opaque access token, it can send a POST request to the introspection endpoint. The response will be a JSON object containing details about the token.

Key fields in the response include active (boolean), scope, client_id, exp (expiration), and sub (subject/user ID).

A successful introspection response for an active token might look like this:

If the token is inactive (e.g., expired or revoked), the response would be: {"active": false}

It's important to differentiate these two concepts:

• Revocation: Changes the state of a token from active to inactive. It's an action performed by the client or authorization server.
• Introspection: Checks the current state of a token. It's a query performed by a resource server to verify a token's validity.

They both contribute to token security but serve distinct purposes.

You have an opaque access token that you suspect might have been compromised. Which action would you take to immediately prevent its further use?

In this lesson, we learned about two crucial aspects of token management: revocation and introspection.

• Revocation: Explicitly invalidates tokens via a dedicated endpoint, essential for security events like logout or compromise.
• Introspection: Allows resource servers to verify the active status and metadata of opaque tokens.

These mechanisms ensure that access granted by tokens remains secure and manageable throughout its lifecycle. Up next, we'll explore advanced OIDC features!