OAuth2架构下资源服务获取Identity Server用户信息的方案咨询

针对你提到的两种思路，我来详细拆解具体实现步骤，顺便聊聊各自的适用场景，帮你做选择：

方案一：客户端获取用户信息后传递给资源服务 #

这种方式适合客户端可信、且用户信息不需要实时同步的场景，步骤很清晰：

• 客户端调用用户信息接口：客户端拿到有效Access Token后，直接向http://identityserver:8080/connect/userinfo发GET请求，请求头带上Authorization: Bearer {你的Access Token}。举个请求示例：

GET /connect/userinfo HTTP/1.1
Host: identityserver:8080
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Ij...

接口会返回用户的附加信息（比如昵称、角色、邮箱这类），客户端可以把这些信息存在内存或者本地存储里。

• 调用API时携带信息：客户端在请求资源服务的接口时，把用户信息通过自定义请求头（比如X-User-Details）或者请求体一起传过去。如果是JSON格式，建议做个Base64编码，避免请求头的格式问题。
• 资源服务接收解析：资源服务在接口层读取对应的请求参数，解析后就能用用户信息了。这里要注意：一定要先验证客户端传来的Access Token的合法性，确保请求是合法用户发起的，再信任传递的用户信息，防止被恶意篡改。

方案二：资源服务自行调用用户信息接口 #

这种方案更适合需要确保用户信息实时性、或者客户端不可信的场景，实现步骤如下：

• 提取客户端传来的Access Token：资源服务收到客户端请求时，先从Authorization请求头里取出Access Token。
• 调用Identity Server的用户信息接口：用拿到的Access Token，向http://identityserver:8080/connect/userinfo发起请求，请求方式和客户端调用完全一样。这里要做好异常处理，比如Token过期、网络超时、接口返回错误码的情况，避免影响业务逻辑。
• 缓存用户信息（推荐）：为了减少对Identity Server的频繁调用，建议把获取到的用户信息缓存起来，缓存时间可以和Access Token的过期时间对齐。比如用Redis或者内存缓存，缓存Key可以用Access Token的哈希值或者用户ID。
• 使用用户信息：拿到用户信息后，就可以直接在业务代码里使用了。这种方式的好处是用户信息直接来自权威的Identity Server，可信度极高，但会增加资源服务和Identity Server的耦合，需要考虑服务调用的稳定性（比如加降级策略）。

选哪个方案？ #

• 如果是内部系统的客户端（比如自家前端），用户信息更新不频繁，选方案一，减少服务间依赖，性能更好。
• 如果用户信息需要实时同步（比如用户刚改了头像，资源服务要立刻拿到最新值），或者客户端是第三方应用（不可信），选方案二，确保信息真实可靠。

内容的提问来源于stack exchange，提问作者Mário Jaroš