基于OpenID Connect实现简单委托认证的后续流程疑问

服务端该接收什么？ #

客户端请求你的业务服务时，只需要在请求头中携带**访问令牌（Access Token）**即可，格式为：

Authorization: Bearer <你的Access Token>

不需要客户端把ID Token传给你的服务——ID Token是给客户端自身用的（比如客户端用来确认用户已登录、获取用户基本信息），业务服务完全不需要直接处理它。

服务端怎么验证令牌有效性？ #

有两种标准方案，选适合你的场景：

• 本地验证（JWT令牌场景）
  如果你的认证服务器发的是JWT格式的Access Token，直接本地验证即可：
  1. 从认证服务器的JWKS端点获取公钥（通常是https://<认证服务器地址>/.well-known/jwks.json）
  2. 验证JWT的签名，确保令牌未被篡改
  3. 检查令牌的核心声明：
     • exp：令牌过期时间，不能早于当前时间
     • aud：受众，必须匹配你的业务服务的Client ID（确保这个令牌是发给你的）
     • iss：发行方，必须匹配认证服务器的地址
• 远程验证（通用场景）
  调用认证服务器的Introspection端点（通常是https://<认证服务器地址>/oauth2/introspect），把Access Token作为参数传过去，服务器会返回令牌的有效性、用户信息等。这种方式适合非JWT格式的令牌，或者你不想维护公钥的情况。注意调用这个端点时，你的服务需要用自己的Client ID和Secret做身份验证。

怎么确定访问令牌对应的用户身份？ #

• 如果是本地验证JWT：直接解析JWT的Payload部分，其中sub字段是用户的唯一标识，还可能包含email、name等其他用户声明（取决于认证服务器的配置）。
• 如果用远程Introspection：端点返回的响应里会包含sub字段，以及其他用户相关的元数据。
• 若需要更详细的用户信息：你的服务可以拿着Access Token调用认证服务器的UserInfo端点，获取完整的用户资料，这个流程比让客户端传信息更安全，避免客户端篡改数据。

关键注意事项 #

• 一定要验证aud字段，防止其他服务的令牌被拿来访问你的服务
• 令牌过期后，返回401 Unauthorized状态码，让客户端重新引导用户获取新令牌
• 不要把Access Token存在服务端，每次请求都实时验证即可

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