Liberty中OIDC访问令牌出站传播配置及相关疑问咨询

1. 设计方案是否合理？ #

这个方案完全合理，属于典型的OIDC保护前后端分离架构：UI作为OIDC客户端完成用户认证，再将令牌传递给BFF（后端聚合层），由BFF统一处理与后端服务的交互，既符合OIDC的安全模型，也能避免前端直接暴露敏感的API访问凭证，提升整体安全性。

2. 如何让UI端Liberty无需编码传播访问令牌？ #

Liberty的oidcClient-1.0特性本身支持自动的令牌出站传播，只需在UI的server.xml中做以下配置即可实现无编码传播：

1. 确保启用oidcClient-1.0和appSecurity-3.0特性
2. 在oidcClient配置中开启令牌传播功能

示例配置：

<featureManager>
  <feature>oidcClient-1.0</feature>
  <feature>appSecurity-3.0</feature>
  <!-- 如果需要HTTPS调用BFF，还需启用ssl-1.0 -->
  <feature>ssl-1.0</feature>
</featureManager>

<oidcClient id="uiOidcClient"
            clientId="你的UI客户端ID"
            clientSecret="你的UI客户端密钥"
            issuerURI="你的企业OIDC OP的issuer地址"
            tokenPropagation="true"/>

当UI应用完成用户认证后，Liberty会自动将访问令牌以Authorization: Bearer <token>的格式添加到调用BFF的请求头中，无需任何代码修改。注意要确保BFF端同样配置了OIDC客户端（或资源服务器）来验证这个访问令牌。

3. 应传播访问令牌还是ID Token？ #

优先传播访问令牌，原因如下：

• ID Token的核心作用是证明用户已完成认证，它的受众（aud声明）是UI客户端，BFF作为资源服务器验证ID Token时会因受众不匹配而失败，且ID Token通常短时效、不适合作为API访问凭证。
• 访问令牌的受众是资源服务器（即你的BFF），是专门用于访问受保护API的凭证。如果BFF需要用户基础信息，有两种方式：
  1. 如果访问令牌是JWT格式，且OP已将所需用户声明（如sub、name等）嵌入其中，BFF可直接解析令牌获取信息；
  2. 如果访问令牌是不透明令牌，BFF可以用它调用OIDC OP的用户信息端点来获取用户数据。

如果确实需要ID Token中的特定信息，可以让UI额外传递，但绝对不能用ID Token作为BFF请求的认证凭证，必须用访问令牌。

4. WASOidcClient_*** cookie的相关问题 #

• 作用：这是Liberty OIDC客户端生成的会话Cookie，用于存储UI端的OIDC会话状态，包括用户认证状态、令牌缓存（如refresh token）等，维持用户在UI端的登录会话，避免重复认证。
• 能否跨Liberty实例认证：不行。该Cookie的内容是用UI Liberty实例的密钥加密的，且默认绑定UI的域名、路径，BFF的Liberty实例无法解密和复用它来完成认证。
• 名称是否可配置：可以。在oidcClient配置中通过cookieName属性自定义名称，示例：

<oidcClient id="uiOidcClient"
            cookieName="MyCustomOidcCookie"
            .../>

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