在play-pac4j中保留OIDC的id_token用于登出的可行性咨询

我们在开源公益项目CiviForm中使用play-pac4j，目前正在为OIDC开发登出支持。按照相关方案建议，我们尝试在会话中存储自定义OidcProfile子类的实例，但遇到问题：回调处理时，profile会被清理，且id_token在存入会话前会被OidcProfile的默认实现移除，导致登出请求无法获取id_token。

我们计划通过重写自定义OidcProfile子类的removeLoginData()方法来保留id_token，但不清楚基础实现移除id_token的原因，想了解这么做是否存在风险。

基础实现移除id_token的原因 #

• 缩减会话存储体积：id_token是登录阶段的一次性凭证，登录完成后用户核心身份信息已解析到profile中，保留它会增加会话数据大小。若使用Cookie存储会话，体积过大可能触发浏览器的Cookie大小限制（通常为4KB），导致会话数据无法正常存储。
• 降低敏感信息泄露风险：id_token是Base64编码的JWT，内容可解码，包含用户身份、过期时间等敏感数据。长期存储在会话中，一旦会话被劫持（比如XSS攻击），攻击者可获取并解析出敏感信息，甚至利用未过期的id_token发起恶意请求。
• 契合OIDC规范设计意图：OIDC中id_token主要用于登录时的身份验证，多数提供商的登出接口并不强制要求传入id_token，默认实现认为登录完成后该凭证已完成使命，无需保留。

保留id_token的潜在风险 #

• 会话存储异常：若依赖Cookie存储会话，额外的id_token会增大Cookie体积，超出限制后可能导致会话丢失或数据损坏。
• 敏感数据泄露概率提升：如上述原因，id_token的长期存储会增加被窃取和滥用的风险，提升系统的安全隐患。
• 维护成本增加：自定义removeLoginData()方法需要长期跟进pac4j的版本更新，若后续基础实现变更，可能引发兼容性问题。

更安全的替代方案 #

• 临时存储按需取用：不在profile中长期保留id_token，而是在登录回调完成后，将其单独存入加密的短期会话存储中，发起登出请求时取出使用，完成后立即删除。
• 利用OIDC会话管理机制：如果所用OIDC提供商支持，可通过session_state或check_session_iframe机制管理会话，无需依赖id_token完成登出操作。

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