前阵子帮团队调一个第三方登录集成的老问题授权码流程走完ID Token 也顺利解析了结果发现用户头像、昵称这些资料一个都拿不到日志里只有一串报错。排查到最后问题就出在/connect/userinfo端点的调用时机和 Claims 合并规则上。如果你也在用 Spring Security 做 OIDC 登录或者在折腾“ID Token 里的 sub 到底能不能当用户唯一标识”“为什么我已经配了 profile 和 email scopeUserInfo 里还是没有头像”这类问题那这篇内容大概率能帮你省几个小时。这篇文章围绕 Spring Security 7 下的 OIDCOpenID Connect登录链路专门拆解/connect/userinfo端点的作用以及它和 ID Token 的分工、调用方式、常见坑点。无论是刚接触 OIDC 的新手还是已经被用户信息映射折磨过的老手建议都往下看。1. 为什么需要解析 /connect/userinfo 端点先从一个最基础的问题开始既然登录时已经拿到了一个 ID Token为什么还要再调用一次/connect/userinfo这个问题如果没想清楚后面所有配置都会像猜谜一样。1.1 从一次登录请求说起OAuth2 与 OIDC 的分工OIDC 并不是一个全新的协议它是在 OAuth 2.0 的授权框架之上增加了一个“身份层”。OAuth 2.0 只解决“授权”问题也就是客户端拿到了一个 Access Token可以去调用受保护的资源接口而 OIDC 额外解决“认证”问题也就是让客户端知道“当前登录的人到底是谁”。一次完整的 OIDC 授权码登录流程大致长这样用户点击“第三方登录”按钮客户端把用户引导到授权服务器的/authorize端点。用户授权后授权服务器通过回调地址redirect_uri带回一个授权码。客户端拿着授权码向/token端点换取 Access Token 和 ID Token。客户端解析 ID Token确认用户身份。如果需要更完整的用户资料客户端再拿着 Access Token 去调用/userinfo端点。这里的第 4 步和第 5 步就是 ID Token 和/connect/userinfo端点分别负责的事情。Spring Security 在底层已经把第 1 到第 4 步封装得比较完善了开发者通常只需要关心第 4 步之后的解析和映射。1.2 ID Token 为什么只适合“看脸”不适合“要资料”ID Token 在 OIDC 协议里被设计成一个紧凑的 JWTJSON Web Token它的目的非常明确证明认证结果。也就是说ID Token 里的 Claims 是授权服务器对“用户是谁”的声明例如sub用户唯一标识、iss签发者、aud受众、exp过期时间、auth_time认证时间等。但 ID Token 里通常只包含基础信息比如preferred_username、email有时连头像地址都没有。原因也很实际ID Token 体积太大不仅浪费带宽还容易触发 Cookie/session 大小限制而且很多用户资料比如性别、地区、手机号属于敏感信息无脑塞进 ID Token 并不合理。这时候就轮到/connect/userinfo端点登场。它是一个 OAuth 2.0 受保护资源接收 Access Token然后返回一个 JSON 格式的用户资料对象例如{ sub: 12345, name: 张三, given_name: 三, family_name: 张, preferred_username: zhangsan, email: zhangsanexample.com, picture: https://avatar.example.com/zhangsan.jpg }简单来说ID Token 负责“认证”UserInfo 端点负责“补全资料”。两者一前一后配合完成完整的用户信息获取。1.3 Spring Security 7 在这次解析中扮演什么角色Spring Security 从很早的版本开始就内置了 OAuth2 Client 和 OIDC 支持到了 6.x 已经非常成熟Spring Security 7 继续沿用并优化了这套模型。开发者声明一个 OAuth2 客户端配置后框架会自动完成重定向到授权服务器交换授权码解析 ID Token调用 UserInfo 端点构建OidcUser对象。这也就意味着大多数情况下我们并需要不自己动手写RestTemplate去请求 UserInfo 端点但如果不搞清楚框架内部做了什么遇到奇怪问题时照样会手足无措。下面我先把环境和依赖讲清楚再进入真正的实操链路。2. 环境准备与依赖配置把基础打牢写代码之前环境必须先利索。很多配置问题其实都不是协议理解问题而是依赖缺失或者配置项写错了位置。2.1 依赖选型只用 starter 还是引入 OAuth2 Client如果项目基于 Spring Boot最简单的方式是引入spring-boot-starter-oauth2-client它会帮你把 Spring Security、OAuth2 Client 相关依赖全部带进来。举个例子在 Maven 的pom.xml里加上dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-oauth2-client/artifactId /dependency如果你更习惯用 Gradle那就是implementation org.springframework.boot:spring-boot-starter-oauth2-client除了这个 starter 之外通常不需要额外引入 JWT 解析库。Spring Security 内部通过spring-security-oauth2-jose处理 JWT 签名和 ID Token 解码而这个模块会被spring-boot-starter-oauth2-client自动引入。所以哪怕是第一次做 OIDC 接入只要加上这一个依赖基础设施就已经齐了。需要注意版本选择。2025 年这个时间点Spring Boot 3.4 以上对应 Spring Security 6.4而 Spring Security 7 对应的是 Spring Boot 4 时代。如果项目还在用 Spring Boot 2.x那大概率需要对照 Spring Security 5 的 API代码上会有细微差别。下面的代码示例我默认按 Spring Security 6/7 较新版本写接口风格基本一致如果遇到编译问题优先检查是不是引用了旧类名例如WebSecurityConfigurerAdapter这种老写法就别再用了。2.2 配置文件里到底要写什么issuer、client-id、scope 一个不能少配置 OIDC 客户端核心就是一个application.yml。我拿一个相对完整的例子来说明spring: security: oauth2: client: registration: my-oidc: provider: my-provider client-id: my-web-client client-secret: my-secret authorization-grant-type: authorization_code redirect-uri: http://localhost:8080/login/oauth2/code/my-oidc scope: openid, profile, email client-name: My OIDC Provider provider: my-provider: issuer-uri: https://idp.example.com看到这个配置有人可能会有疑问issuer-uri到底起什么作用它的价值在于只要提供一个合法的 issuer 地址Spring Security 会自动去发现该地址下的 OpenID Provider 配置信息。具体来说框架会尝试访问https://idp.example.com/.well-known/openid-configuration从这个发现文档里自动读取/authorize、/token、/userinfo、/jwks等端点地址。这也意味着只要目标授权服务器实现了标准 OIDC 发现协议你就不需要在provider里逐个手写 endpoint 地址。这里有一个非常容易踩的坑如果授权服务器的发现文档不规范或者因为网络原因访问不到这个.well-known地址启动时就会抛出IllegalArgumentException: Unable to resolve the Configuration with the provided Issuer。遇到这种情况有两种处理方式确认issuer-uri足够准确不要漏掉末尾的路径实在不行可以改用显式配置每个端点地址绕开动态发现。显式配置的写法大致如下provider: my-provider: authorization-uri: https://idp.example.com/oauth2/authorize token-uri: https://idp.example.com/oauth2/token user-info-uri: https://idp.example.com/connect/userinfo jwk-set-uri: https://idp.example.com/oauth2/keys其中user-info-uri就是我们今天讨论的/connect/userinfo端点在配置层面的落点。如果授权服务器不支持动态发现这行配置必须写对否则框架压根不会自动调用 UserInfo 端点。2.3 自定义 UserInfoService 的两种常用姿势Spring Security 提供了一个接口OAuth2UserServiceOidcUserRequest, OidcUserOIDC 登录时框架会用它来加载最终的用户对象。默认实现是OidcUserService它内部完成两件事用 ID Token 的 Claims 构造一个OidcUser如果 Provider 配置了user-info-uri会调用 UserInfo 端点并把返回的 Claims 合并到同一个OidcUser中。大多数时候我们不需要重新定义这个 Service只需要在OidcUserService外面包一层做自定义增强。第一种做法是直接加钩子在默认逻辑执行前后做一些日志、数据库同步之类的操作Bean public OAuth2UserServiceOidcUserRequest, OidcUser oidcUserService() { OidcUserService delegate new OidcUserService(); return (request) - { OidcUser oidcUser delegate.loadUser(request); // 在这里可以打印日志、同步用户表 return oidcUser; }; }第二种做法是完全重新实现加载逻辑适合用户体系和 IDP身份提供方差异很大的场景。比如希望直接忽略 UserInfo 端点的返回结果只从 ID Token 构建用户那么可以改写为Bean public OAuth2UserServiceOidcUserRequest, OidcUser oidcUserService() { return (request) - { OidcIdToken idToken request.getIdToken(); OidcUserInfo userInfo new OidcUserInfo(idToken.getClaims()); return new DefaultOidcUser( request.getClientRegistration().getProviderDetails().getUserInfoEndpoint() .getUserNameAttributeName(), idToken, userInfo ); }; }不过说实话第二种方式我实际用得更少因为 UserInfo 端点往往能提供比 ID Token 更丰富的资料直接丢掉有点可惜。做减法之前先确认是否真的不需要那些额外资料。3. 实操走查从授权码到 OidcUser 的完整链路接下来是全文最核心的实操环节。我会沿着 Spring Security 处理 OIDC 登录的实际链路按顺序拆解每一步中 ID Token 和 UserInfo 数据到底存在哪、怎么取、怎么用。3.1 授权码流程中的 Token 交换做了什么当用户从授权服务器跳回我们的回调地址/login/oauth2/code/my-oidc时Spring Security 内部会触发OAuth2LoginAuthenticationFilter。这个 Filter 拿到授权码后使用OAuth2AuthorizationCodeAuthenticationProvider去走 Token 交换。Token 交换的结果是一个OAuth2AccessTokenResponse里面通常包含access_tokentoken_typeexpires_inscopeid_token只有 OIDC 流程才会返回Spring Security 拿到这个响应后会把 Access Token、Refresh Token、ID Token 都封装到OidcAuthorizationCodeAuthenticationToken中然后交给OAuth2LoginAuthenticationProvider。在这个 Provider 中会先校验 ID Token 的签名和 Claims具体包括iss、aud、exp、nonce等。这些校验都是框架自动完成的不需要自己写。校验通过后就会调用我们上面说的OAuth2UserService去加载用户详细信息。也就是说Token 交换并不只是“拿 code 换 token”这一步它后续还串联了 ID Token 验证和 UserInfo 调用。整个过程虽然自动化程度高但如果你能理解它是在哪一环完成了什么后面排查问题就清晰多了。3.2 拿到 OidcUser 后ID Token 和 UserInfo 数据在哪里当OAuth2LoginAuthenticationFilter处理完成最终会往SecurityContext中放入一个OAuth2AuthenticationToken其中的 principal 就是一个OidcUser对象。在 Controller 里最简单的获取方式是这样的GetMapping(/profile) public MapString, Object profile(AuthenticationPrincipal OidcUser oidcUser) { return oidcUser.getClaims(); }如果你在方法参数上直接标注AuthenticationPrincipal OidcUserSpring Security 会自动从当前登录上下文里把用户对象拿出来。这一步之所以能工作是因为框架在认证成功后把OidcUser作为 principal 存了下来。关键点来了OidcUser的这个对象里其实包含了两部分数据。ID Token 的 Claims通过oidcUser.getIdToken().getClaims()可以访问。UserInfo 的 Claims通过oidcUser.getUserInfo().getClaims()可以访问。但平时我们最常用的oidcUser.getClaims()并不是简单返回 ID Token 的 Claims。Spring Security 在构建DefaultOidcUser时会把 UserInfo 的 Claims 合并到 ID Token 的 Claims 之上如果 key 相同UserInfo 的值会覆盖 ID Token 的值。这个合并逻辑非常关键因为很多时候 ID Token 里的email和 UserInfo 里的email可能不一致。遇到这种情况默认取 UserInfo 的最新值来做业务处理通常更合理因为 UserInfo 端点才是用户资料的最新来源。不过这里也有一个值得注意的细节如果只是单纯关心“登录时 ID Token 里声明的身份”和“当前用户资料”是否一致建议把两份 Claims 分开对比而不是直接使用合并后的结果。最常见的做法是写一个对象转换工具把两个 Claims 分别映射到不同的字段。3.3 手动调用 /connect/userinfo什么时候需要自己发起请求大多数场景下框架已经把 UserInfo 端点调用封装好了。但有一些场景你可能会需要自己动手调用希望拿到最新用户资料时比如用户改了头像但当前 Session 里还是旧数据。需要以系统账号身份调用而不是每次都用当前用户的 Access Token。自定义 UserInfo 端点的请求方式比如某些授权服务器要求额外传一个 header 参数。如果确定要手动调用最直接的方式是用RestTemplate或WebClient把 Access Token 放到请求头里。先拿到 Access Token可以通过OAuth2AuthorizedClientManager或者直接从OAuth2AuthenticationToken里拿GetMapping(/refresh-userinfo) public MapString, Object refreshUserInfo( AuthenticationPrincipal OidcUser oidcUser, OAuth2AuthorizedClientService authorizedClientService, HttpServletRequest request) { String clientRegistrationId my-oidc; OAuth2AuthenticationToken authToken (OAuth2AuthenticationToken) SecurityContextHolder.getContext().getAuthentication(); OAuth2AuthorizedClient authorizedClient authorizedClientService.loadAuthorizedClient( clientRegistrationId, authToken.getName()); String accessToken authorizedClient.getAccessToken().getTokenValue(); String userInfoUri authorizedClient.getClientRegistration() .getProviderDetails().getUserInfoEndpoint().getUri(); // 用 RestTemplate 发起 GET 请求 HttpHeaders headers new HttpHeaders(); headers.setBearerAuth(accessToken); ResponseEntityString response restTemplate.exchange( userInfoUri, HttpMethod.GET, new HttpEntity(headers), String.class); return objectMapper.readValue(response.getBody(), Map.class); }这里有个容易被忽略的问题Access Token 是有过期时间的。如果用户在页面上停留了很久才点击“刷新资料”这时 Access Token 可能已经失效直接调用 UserInfo 端点会返回401。更稳的办法是先用OAuth2AuthorizedClientManager重新获取或刷新 Access Token再发起请求。如果授权服务器支持 Refresh Token建议在配置里加上refresh-token的 scope并确保授权返回了 refresh_token。3.4 把 Claims 映射成项目里的 UserProfile 对象拿到 Claims 之后真正落地的还是把它转成自己项目里的领域对象。我习惯的做法是定义一个有明确语义的UserProfile类而不是到处传MapString, Object。public record UserProfile( String subject, String username, String email, String displayName, String avatarUrl, Instant authTime, MapString, Object rawAttributes ) { }然后在 Controller 或 Service 层写一个转换方法private UserProfile toUserProfile(OidcUser oidcUser) { MapString, Object claims oidcUser.getClaims(); return new UserProfile( oidcUser.getSubject(), (String) claims.get(preferred_username), oidcUser.getEmail(), (String) claims.get(name), (String) claims.get(picture), oidcUser.getAuthTime(), Map.copyOf(claims) ); }如果授权服务器返回的字段名称非常规可以在application.yml里通过provider.user-info-uri无法解决需要看是否支持自定义 mapping。Spring Security 有一个配置项spring.security.oauth2.client.provider.my-provider.user-info-authentication-method: header spring.security.oauth2.client.provider.my-provider.user-info-uri: https://idp.example.com/connect/userinfo但这里要说明的是OIDC 标准客户端通常没有一个统一的“字段映射”配置很多映射逻辑还是要在代码里完成。如果不想每次手工写get(snake_case_key)这种代码可以考虑引入 Jackson 的PropertyNamingStrategy把 JSON 字段自动转成驼峰命名。这种方式在字段特别多的时候能省很多事。4. 常见问题与排查技巧实录这一部分我把自己实际踩过、帮别人排查过的问题整理成一张速查表再针对几个典型场景展开讲讲。每个问题后面我都会写上排查思路因为很多时候解决办法本身不值钱怎么想到这个办法才值钱。现象可能原因解决思路启动报Issuer相关错误issuer-uri配置错误或发现文档不可达检查.well-known地址或改显式端点配置登录成功但拿不到用户资料scope 缺少openid或未配置 user-info-uri确认 scope 包含 openid检查 provider 配置调用 userinfo 返回 401Access Token 过期或 scope 不足刷新 token检查 userinfo 端点需要哪些 scopeuserinfo claims 与 id_token claims 冲突合并策略默认 userinfo 覆盖 id_token区分使用场景分开读取两份 claims集群环境下 session 丢失OidcUser 序列化问题使用可序列化的 claims或引入外部 session 存储4.1 ID Token 解析失败签名、issuer、nonce 逐个排查先说一个最常见的启动期问题ID Token 解析失败。通常表现为日志里出现类似JwtException或者InvalidTokenException。排查顺序我建议是从下往上签名验证失败。Spring Security 会从jwk-set-uri拉取公钥如果授权服务器的 JWKS 轮换不及时或者本地的JwkSetUri缓存了旧公钥就会验签失败。可以尝试重启应用或者清掉框架内部缓存的 JWK 集合。另外确认授权服务器返回的kid确实存在于 JWKS 里。issuer 不匹配。ID Token 里的iss必须和我们在 Provider 里配置的issuer-uri完全一致包括末尾的斜杠都不能省略。很多授权服务器会不区分大小写但有部分严格实现任何不匹配都会导致校验失败。nonce 校验失败。nonce 是防止重放攻击的重要手段。正常登录流程中浏览器存储的 nonce 和 ID Token 里的 nonce 必须一致。如果应用使用了分布式会话但没有正确共享缓存就可能出现在 A 节点发起登录、B 节点处理回调的跨节点情况导致 nonce 对不上。解决方案是引入外部会话存储确保非对称环境下也能拿到同一个 nonce。audience 不匹配。ID Token 的aud必须包含当前客户端注册的client-id。有些授权服务器还会额外加一个azp声明如果校验环节发现aud太窄或者不匹配也会抛出异常。如果这些都没问题再看一下是不是 ID Token 字符串本身被截断了。之前就有人把整个日志链路里打印出来的 ID Token 复制出来做校验但日志编辑器自动换行把 JWT 切成几段拼回去的时候少了一段签名结果怎么验都不对。建议调试时先把 JWT 写入临时文件再对比断点截到的原始值。4.2 UserInfo 端点返回 401/403scope 和 audience 的坑UserInfo 端点返回 401最直接的原因是 Access Token 无效或过期。但如果你确定 Access Token 刚拿到就过期那大概率是授权服务器默认的 Access Token 有效期太短比如只有 5 分钟而你是在浏览器里手动输入代码等待测试拖太久自然失效。另一种 401 情况是 Bearer Token 没传对。检查一下请求头是不是长这样Authorization: Bearer [access_token]少写空格或者写成了Basic都会直接被拒。403 的情况通常更微妙往往是 Token 里没有包含 UserInfo 端点所需的scope。比如你只申请了openid profile但 UserInfo 端点要求必须携带emailscope 才能返回email字段甚至必须携带某个自定义 scope 才能访问。这时点击查看授权服务器对外提供的 scope 和 UserInfo 端点文档把它们补充到客户端的scope配置里重新走一遍登录流程让新 scope 生效。还有一个我遇到过有点冷门的问题有些授权服务器的 UserInfo 端点不只校验 scope还会校验 Access Token 的 audience。也就是说这个 Access Token 必须明确是为该 UserInfo 端点颁发的否则即便 scope 够了也会返回 403。这种情况下需要检查授权服务器的 token 签发逻辑确认 Audience 是否包含 UserInfo 端点对应的资源标识。4.3 UserInfo Claims 和 ID Token Claims 不一致怎么办当同一个字段比如email在 ID Token 和 UserInfo 里都有但值不一样时框架默认把 UserInfo 的 Claims 合并进最终 Claims。具体逻辑是在DefaultOidcUser的构造过程中先取 ID Token Claims再将 UserInfo Claims 的putAll进去因此同名字段会被覆盖。如果你希望优先使用 ID Token 里的值这里有两个选择配置层面改成只使用 ID Token不调用 UserInfo 端点。代码层面分别从getIdToken().getClaims()和getUserInfo().getClaims()读取再做业务合并。在我的实际项目里通常都是把两份 Claims 存到自己的用户表里保留原始值同时记录一个“用户最近更新时间”来判断该信哪个。比如用户改了头像授权服务器会先从 UserInfo 端点提供新头像地址但 ID Token 可能签发于改动之前所以过期 ID Token 里的旧头像不应该覆盖新头像。这种情况下UserInfo 优先的合并策略反而是正确的。如果你在开发调试时发现 UserInfo 和 ID Token 的sub都不一样那就不是简单覆盖的问题了而是授权服务器实现有问题。OIDC 规范要求二者指向同一用户强烈建议看下授权服务器日志或者提工单反馈。4.4 动态 issuer 和集群环境下的 session 序列化问题这里再讲一个进阶一点的场景如果你的授权服务器有多个环境比如地区化部署每个环境的 issuer 不同但客户端需要统一配置这时候可以把 issuer 改成动态获取。最常见的做法是把issuer-uri放到配置中心每个环境单独维护一份。如果觉得这还不够灵活可以在启动时通过一个自定义的ClientRegistrationRepository动态构造ClientRegistration用代码决定providerDetails.issuerUri的实际值。这种做法适合多租户系统但复杂度也会相应提高。集群环境下容易忽略的是OidcUser的序列化。Spring Security 默认会把Authentication对象写入 Session。如果 Session 存储在 Redis 等外部缓存中那么OidcUser就必须是可序列化的。框架内部使用的DefaultOidcUser默认实现了Serializable但其内部的 Claims 往往是一个LinkedHashMap这种类型本身也能序列化。最容易出问题的反而是自定义 Claims。比如你在自定义OidcUserService里往 Claims 中追加了Instant、LocalDate等时间类型或者放进了自定义的 Java 对象而它们没有实现Serializable那么在跨节点读取 Session 时就会抛SerializationException。解决方式有两种给自定义 Claims 里的所有对象实现Serializable。或者在OidcUserService中把 Claims 转换为兼容的数据结构例如统一转成String或Long。我个人更倾向后者因为这会迫使你认真对待 Claims 的边界不把临时数据塞进去。排查思路可以分三步走先复现序列化异常拿到完整堆栈再定位是哪个字段导致的最后在自定义OidcUserService里输出 JSON 化的 Claims确认是否全部是基础类型。记住一个原则写入 Session 的数据越“干净”将来做水平扩展时越省心。5. 一些被问得比较多的细节补充除了上面四个大块的实操和排查我还想补充几个平时很容易被问到的细节。这些点单独拎出来可能不够撑起一整章但确实经常让人卡壳。5.1 用户信息分组Store OAuth2AuthorizedClient默认情况下Spring Security 会把授权后的OAuth2AuthorizedClient保存到OAuth2AuthorizedClientService。如果你希望在用户退出登录时主动撤销 Access Token需要用到这个对象里的 Refresh Token。比如Autowired private OAuth2AuthorizedClientService authorizedClientService; public void revoke(OAuth2AuthenticationToken authentication) { OAuth2AuthorizedClient authorizedClient authorizedClientService.loadAuthorizedClient( authentication.getAuthorizedClientRegistrationId(), authentication.getName() ); // 调用授权服务器 token revocation 端点 }如果忘了保存 authorized client后面想主动调 Revocation 端点就很麻烦可能还得让用户重新登录一次。所以务必确认OAuth2AuthorizedClientService使用的是 JPA、Redis 还是默认的内存实现内存实现在应用重启后会丢失生产环境建议至少换到 Redis。5.2 Logout 之后 UserInfo 还能不能用OIDC 的 Logout 和 UserInfo 端点是两个独立的东西。Logout 只负责清理应用和授权服务器之间的会话而之前签发的 Access Token 在有效期内还是可以继续访问 UserInfo 端点除非授权服务器因为会话注销主动撤销了这个 Token。所以在做单点登出时不要默认 Access Token 已经失效要在调用 UserInfo 端点时做好 401 兜底。比较好的实践是在成功登出后应用本地把 Token 标记为失效并主动调用授权服务器的 Revocation 端点双保险。5.3 安全配置中放行哪些路径很多 OIDC Demo 会把所有路径都保护起来这样用户一访问根路径就被重定向到登录页。如果只是做登录验证可以这样配置Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth - auth .requestMatchers(/login/**, /oauth2/**).permitAll() .anyRequest().authenticated() ) .oauth2Login(oauth2 - oauth2 .loginPage(/login) .defaultSuccessUrl(/profile) ); return http.build(); }这里的/oauth2/**必须放行因为回调地址和 token 相关端点都在这个路径下如果被拦截整个登录过程会再次重定向形成死循环。6. 写在最后我的一些体会做了这么多 OIDC 接入之后我的直观感受是Spring Security 已经把脏活累活挡掉了一大半但它在带给我们便利的同时也把很多细节藏在了黑盒里。比如/connect/userinfo端的自动调用这个行为藏在OidcUserService内部如果不看框架源码很难解释为什么同一个属性在登录前后的值会不一样。但也正是这种“黑盒”逼着我们去理解 OIDC 协议本身的边界ID Token 是给客户端证明身份用的UserInfo 端点才是拿用户资料的正主。最后再分享一个小技巧调试 OIDC 问题时不要一上来就在 Java 代码里打断点。先打开浏览器开发者工具看 Network 面板里的跳转链路确认/authorize、/token、/userinfo三个请求分别发了什么参数、带了什么 Token。很多时候问题在第一步就暴露了根本轮不到看 Java 代码。等请求链路清晰了再回到代码里排查不迟。这样调试的效率比闷头看堆栈高很多。希望这篇内容能帮你把 OIDC 登录链路理得更顺。
