资源服务器与认证服务器分离时的身份验证及AccessToken存UserId合理性问询

Awesome questions—let’s tackle them one by one, since they hit on some core OAuth2 mechanics for distributed systems.

When your authentication server and resource server are completely independent, the resource server can’t directly validate a user’s identity on its own. Instead, it relies on the access token provided by the client to prove the user has been authenticated. There are two standard, battle-tested approaches to handle this:

• Token Introspection: The resource server sends the received access token to the auth server’s dedicated introspection endpoint (defined in RFC 7662). The auth server checks if the token is valid, active, and tied to a legitimate user, then returns key details like the user’s ID, assigned scopes, and expiration time. This is perfect for "reference tokens"—tokens that don’t carry user data themselves, just a pointer to the auth server’s internal records.
• Self-Contained Tokens (JWT): If your access token is a JSON Web Token (JWT), it’s signed (and optionally encrypted) by the auth server. The resource server can verify the token’s signature using the auth server’s public key (no need to make a round-trip call every time). The JWT payload can include claims like sub (short for "subject," which is typically the user’s unique ID), so the resource server can extract this directly to confirm the user’s identity. This is more efficient, but you need to manage key rotation properly to keep things secure.

In both cases, the resource server never authenticates the user directly—it trusts the auth server’s validation of the token as proof of the user’s identity.

This is absolutely a reasonable and widely used practice, but there are a few important considerations to keep in mind:

• Token Type Is Key: If you’re using a JWT (self-contained token), embedding the user ID (usually as the sub claim) is standard practice. The resource server can verify the JWT’s signature to ensure it hasn’t been tampered with, then safely pull the user ID to query its own database (like fetching the user’s posts). This cuts down on unnecessary calls to the auth server, which is a big win for performance.
• Security Best Practices: Even though a user ID isn’t typically sensitive, you still need to secure the token properly:
  • Always sign the JWT with a strong asymmetric algorithm (like RS256) so the resource server can verify authenticity without sharing a secret key.
  • Set a reasonable expiration time (exp claim) to limit the window of risk if a token is compromised.
  • Avoid adding sensitive data (like passwords or personal contact info) to the token payload—stick to non-sensitive identifiers like user ID.
• Edge Cases to Plan For: If your system needs to invalidate tokens early (e.g., a user logs out or their permissions change), self-contained tokens can be tricky because the resource server has no way of knowing the token is invalid unless you implement a token revocation list (which adds complexity). In that scenario, using reference tokens with introspection might be a better fit, since the auth server can immediately mark the token as invalid.

Overall, storing the user ID in the access token is a practical approach for password grant flows, especially when you want the resource server to operate independently without frequent auth server calls—just make sure you follow security best practices for token management.

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