配置UAA以CAS5为IDP时Pac4j Session profile缺失accessToken

我之前帮团队排查过类似的UAA+CAS5集成问题，你遇到的这个Pac4j Profile环节accessToken缺失的问题，大概率是几个配置细节没处理好，咱们一步步来理：

1. 核对UAA端CAS身份提供商的核心配置 #

• 确保UAA的uaa.yml里CAS IDP配置的authorization-grant-type设为authorization_code——这是触发授权码模式的关键，只有走这个模式，才会有后续获取accessToken的流程。
• 严格校验redirect-uri和CAS端注册的回调地址完全一致：包括协议（http/https）、域名、端口，甚至末尾的斜杠都不能错，CAS对回调地址的校验非常严格，细微差异都会导致流程异常。
• 确认client-id和client-secret和CAS端注册的应用信息完全匹配，这两个参数错误会直接导致获取accessToken时鉴权失败，进而在Pac4j环节拿不到token。

2. 检查CAS端Pac4j的配置细节 #

• 在CAS5的cas.properties里，确保启用了Pac4j的accessToken支持：cas.authn.pac4j.core.callback-url要正确指向CAS的回调端点，同时cas.authn.pac4j.oauth2.client[0].access-token-url必须准确配置为CAS的/cas/accessToken接口。
• 确认CAS的Pac4j客户端配置开启了useAuthorizationCodeFlow开关——这个配置控制是否走授权码流程获取accessToken，如果没开启会直接跳过token获取步骤，自然会导致后续环节缺失token。

3. 抓包分析UAA到CAS的accessToken请求 #

• 用抓包工具捕获UAA向CAS发送的/cas/accessToken请求，重点检查是否包含这几个必填参数：code（授权码）、client_id、client_secret、redirect_uri：
  • 如果code参数缺失，说明UAA在回调环节没有正确提取授权码，需要检查UAA的cas-service-provider.xml或相关Java配置里的回调处理逻辑。
  • 如果参数都完整但CAS返回错误，去翻CAS的日志（尤其是org.pac4j相关的日志），里面会详细记录token获取失败的具体原因，比如授权码已过期、客户端权限不足等。

4. 验证CAS的token存储与过期设置 #

• CAS5默认的accessToken存储是内存级别的，如果UAA和CAS不在同一个JVM，或者CAS中途重启过，之前生成的授权码对应的token可能已经丢失，导致获取失败。可以考虑配置分布式存储（比如Redis）来持久化token，或者通过cas.tokens.access-token.time-to-live-in-seconds调整token的过期时间。
• 同时检查授权码的过期时间（cas.tokens.authorization-code.time-to-live-in-seconds），如果授权码在UAA发起请求前就过期了，也会导致accessToken获取失败。

还有个容易忽略的点：如果UAA和CAS之间用了HTTPS，要确保两边的SSL证书信任配置正确——UAA的JVM必须信任CAS的证书，否则请求可能在底层就失败，表面上看起来是Pac4j环节缺失token。

内容的提问来源于stack exchange，提问作者Ryan R.