资源服务器如何无需联系授权服务器即可验证access token？

关于validate的具体含义 #

这里提到的token验证，核心是完成三项校验，全部通过才会认可token有效：

• 确认token是受信任的授权服务器签发，而非第三方伪造
• 确认token未超出预设有效期，没有过期
• 确认token携带的权限范围、受众、绑定用户标识等声明未被篡改，且符合当前访问接口的准入要求

资源服务器独立验证access token的实现逻辑 #

你的猜测方向是对的，但要区分两种签名机制的细节，整个验证流程完全不需要授权服务器实时参与：

• 如果使用对称签名算法（如HS256）：授权服务器和资源服务器会提前共享同一组签名密钥，资源服务器收到access token后，用本地存储的共享密钥对token内容重新计算签名，和token自带的签名值比对，一致就说明token来源可信、内容未被篡改。
• 如果使用非对称签名算法（如RS256、ES256，是目前生产环境的主流方案）：授权服务器自己单独保管私钥，私钥仅用于签发token，绝对不会分发给任何其他服务；资源服务器只需要提前获取授权服务器公开的公钥，公钥仅能用于验签，无法用来生成合法的token签名。验签时资源服务器在本地用公钥解密token携带的签名值，和本地计算出的token内容哈希值比对，匹配即可完成来源和完整性校验。

完成签名校验后，资源服务器只需要在本地检查token的过期时间、权限范围、受众字段是否符合要求，全程不需要发起对授权服务器的网络请求。

这种验签模式不会让授权服务器失去存在价值 #

本地验签只是省掉了高频access token验证的网络开销，授权服务器的核心作用完全不可替代：

• 只有授权服务器持有签名私钥，所有token签发、续期操作都必须由它完成：用户首次登录的身份校验、权限审批、初始access/refresh token签发，access token过期后用refresh token换发新token的流程，都只能在授权服务器完成，资源服务器持有的公钥没有签发token的能力。
• refresh token的验证必须对接授权服务器：refresh token是长有效期凭证，本身一般是不透明字符串，不携带自包含的权限信息，授权服务器会存储所有有效refresh token和用户、客户端的绑定关系，还要处理用户修改密码、主动登出、token被盗吊销、权限变更等实时性要求高的场景，必须由授权服务器实时校验refresh token的有效性，资源服务器没有这部分核心数据。
• 授权服务器承载了所有身份体系核心逻辑：用户名密码校验、多因素认证、第三方身份源对接、权限范围管控、token黑名单维护等能力，都是资源服务器不会也不应该承载的，两者是明确的分工关系，不存在替代可能。

这种分离设计的核心优势就是平衡性能和安全：access token有效期极短（通常几分钟到半小时），请求频率极高，本地验签可以避免授权服务器成为全链路的性能瓶颈；refresh token请求频率极低（仅在access token过期时发起一次），走授权服务器实时校验可以保证长周期凭证的安全性。

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