oauth/check_token/与oauth/token_key/端点的用途、使用场景及配置问询

Great question—let's unpack these two critical Spring Security OAuth2 endpoints, what your configuration does, and when you'd use each one in practice.

1. Core Definitions #

First, let's clarify what each endpoint is designed to do:

oauth/token_key/ #

This endpoint is the authorization server's way of exposing its public key for validating signed JWT (JSON Web Token) signatures. If your auth server issues JWTs (specifically JWS—signed tokens), any service that needs to verify those tokens (like resource servers) needs this public key to confirm the token hasn't been tampered with.

oauth/check_token/ #

This is a centralized token validation endpoint. When a resource server receives an access token from a client, it can send a request here to verify that the token is:

• Not expired
• Not revoked
• Issued by the correct authorization server
• Scoped appropriately for the requested resource

2. What Your Configuration Does #

Let's break down your specific security setup:

@Override 
public void configure(final AuthorizationServerSecurityConfigurer oauthServer) { 
    oauthServer.tokenKeyAccess("permitAll()").checkTokenAccess("isAuthenticated()"); 
}

For oauth/token_key/ #

tokenKeyAccess("permitAll()") opens this endpoint to unrestricted, anonymous access. This makes perfect sense because public keys are intended to be public—resource servers or third-party services shouldn't need to authenticate just to fetch the key needed to verify tokens. It's a standard default for JWT-based OAuth2 setups.

For oauth/check_token/ #

checkTokenAccess("isAuthenticated()") restricts this endpoint to only authenticated entities. Typically, this means only registered resource servers (which are set up as clients with the authorization server) can call this endpoint. You don't want unauthenticated actors using this endpoint to probe valid tokens or enumerate active sessions.

3. Practical Usage & Scenarios #

Let's cover how to use each endpoint and when they're most useful:

oauth/token_key/ #

• How to use: Send a simple GET request to [your-auth-server-base-url]/oauth/token_key/. The response will return the public key in a standard format (usually JWK or PEM, depending on your configuration).
• Common use cases:
  • Resource servers that don't have the public key pre-configured can dynamically fetch it to validate JWTs on the fly.
  • Third-party services integrating with your OAuth2 ecosystem need a reliable way to get the public key for token verification.
  • Eliminates the hassle of manually distributing and updating public keys across all resource servers—they can pull the latest key directly from this endpoint.

oauth/check_token/ #

• How to use: An authenticated client (usually a resource server) sends a POST request to [your-auth-server-base-url]/oauth/check_token/ with the parameter token=[the-access-token-to-validate]. The response will return details like the token's expiration time, scope, associated client ID, and a boolean indicating if it's valid.
• Common use cases:
  • When using opaque tokens (non-JWT tokens that can't be validated locally)—resource servers have to delegate validation to the auth server's authoritative source of truth.
  • Even with JWTs, you might use this endpoint if you need to check if a token has been revoked (JWTs don't include real-time revocation status by default).
  • Centralized token management: Instead of each resource server implementing its own validation logic, they rely on the auth server to confirm token validity.

内容的提问来源于stack exchange，提问作者Mohammad Yazdian