OAuth2中资源服务器如何通过令牌识别用户及获取权限？

Great question—this is one of the most common pain points when wrapping your head around OAuth 2.0, especially when dealing with separate authorization and resource servers. The short answer is: it depends on the type of Access Token you're using, but there are two main approaches:

1. 自包含令牌（比如JWT）：直接从令牌获取信息 #

If your Access Token is a JSON Web Token (JWT), the resource server can validate and extract user identity/permission data directly from the token itself—no backend calls to the authorization server needed. Here's how it works:

• A JWT is split into three parts: header (algorithms used), payload (the actual data like user ID sub, granted scopes scope, expiration time exp), and signature.
• The authorization server signs the JWT using a private key. The resource server holds the corresponding public key, which it uses to verify that the token hasn't been tampered with.
• Once verified, the resource server can read the payload claims to know exactly who the user is and what they're allowed to do (e.g., "user 123 has permission to read /api/posts").

This is the most common approach these days because it's fast—no extra network calls mean better performance for your resource server. Just make sure you keep the public key updated if the authorization server rotates its keys!

2. 引用式令牌：需要与授权服务器后端通信 #

If your Access Token is a reference token (just a random, opaque string that doesn't contain any meaningful data), the resource server has to reach out to the authorization server to get the token's details. Here's the flow:

• The client sends the reference token to the resource server.
• The resource server calls the authorization server's Token Introspection Endpoint (defined in RFC 7662), passing the reference token.
• The authorization server checks its internal storage, then returns a response with the token's validity, user identity, granted scopes, and other metadata.

This approach is useful if you need to:

• Keep sensitive user data out of the token (since the token itself is just a pointer)
• Revoke tokens in real time (the authorization server can immediately tell the resource server if a token is no longer valid)
• Enforce strict, centralized control over token validity

Quick Recap #

• Use JWTs for most cases: fast, self-contained, no backend calls required (as long as you handle key management properly).
• Use reference tokens + introspection when you need real-time token revocation or want to avoid exposing data in the token.

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