wso2~通过三方IDP的token置换wso2的token

参数：https://datatracker.ietf.org/doc/html/rfc7523

oauth2.0中的三方另类授权

了解OAuth 2.0中特定的授权类型（Grant Type）对于构建安全的认证流程至关重要。下面为你详细介绍这三种基于URN声明的扩展授权类型。

🔐 设备代码授权 (urn:ietf:params:oauth:grant-type:device_code)

这种授权模式专为输入能力受限或没有浏览器的设备设计，比如智能电视、游戏机、IoT设备或命令行工具（CLI）。

• 工作原理：其核心是一个两步过程。

  1. 设备获取代码：设备上的应用首先向授权服务器（如 Microsoft Entra ID）的 /devicecode 端点发起请求。服务器会返回一组信息，包括一个简短的 user_code（用户代码）和一个 verification_uri（验证网址）。
  2. 用户授权：设备将 user_code 和 verification_uri 显示给用户，并提示用户在其他设备（如个人手机或电脑）上打开浏览器，访问该网址并输入代码。用户在授权服务器的正规页面上完成身份验证（可能包括多因素认证）并同意授权。在此期间，设备应用会定期轮询授权服务器的令牌端点，直到用户完成操作后获取访问令牌和刷新令牌。

• 安全风险与防御：需要注意的是，此流程可能被用于进行高迷惑性的网络钓鱼攻击（称为“设备代码钓鱼”）。攻击者会诱导用户在真实的微软登录页面输入由攻击者生成的设备代码，从而授权一个恶意应用。防御措施包括在服务器端严格限制应用同意策略、实施条件访问策略（如要求来自合规设备），以及对用户进行安全教育。

🔄 令牌交换授权 (urn:ietf:params:oauth:grant-type:token-exchange)

令牌交换授权提供了强大的 interoperability（互操作性），允许将一个凭证或令牌交换为另一个不同的令牌，常用于服务之间的安全调用或身份映射。

• 核心概念：它遵循 OAuth Token Exchange 规范，使得客户端能够使用一个现有的 subject_token（主体令牌）来换取一个新的、针对不同受众或资源的 access_token（访问令牌）。

• 常见场景：

  • 服务间调用：后端服务A可以使用自己持有的令牌，换取一个具有适当权限的、用于调用服务B的访问令牌。
  • 权限降级：一个高权限的应用在需要调用一个低信任度的服务时，可以换一个权限受限的令牌，以提升安全性。
  • 外部身份提供商集成：将外部IDP（如Google、Facebook）签发的令牌交换为内部系统的令牌，从而实现跨域身份联合。
  • 用户模拟：在严格管控下，服务可以换取一个代表特定用户身份的令牌（即模拟用户）。

• 实施要点：令牌交换功能通常默认不开启，需要在服务器端（如Red Hat Single Sign-On）为客户端显式配置精细的权限策略。

⚙️ JWT持有者授权 (urn:ietf:params:oauth:grant-type:jwt-bearer)

这种授权类型允许客户端直接使用一个预先签名的JWT（JSON Web Token）作为断言（assertion）来获取访问令牌。

• 基本流程：客户端向授权服务器的令牌端点发起POST请求，在请求体中，grant_type 参数设置为 urn:ietf:params:oauth:grant-type:jwt-bearer，并同时提供用作断言的 assertion 参数（即JWT本身）。授权服务器会验证该JWT的签名、有效期、颁发者等信息，验证通过后即颁发所请求的访问令牌。

• 典型应用场景：

  • 服务账户认证：在机器对机器（M2M）的通信中，一个服务可以使用事先配置好的JWT（通常基于私钥签名）来获取访问令牌，无需用户交互。这在CI/CD流水线或后台服务中非常常见。
  • 微服务架构：在微服务网络中，一个服务在收到访问令牌后，可以利用此流程向认证服务器换取一个范围（scope）更窄、专用于访问另一个特定微服务的令牌。

下面的表格清晰地对比了这三种授权类型的关键差异。

特性	设备代码授权 (device_code)	令牌交换授权 (token-exchange)	JWT持有者授权 (jwt-bearer)
主要目的	方便输入受限设备上的用户授权	实现令牌之间的安全转换和身份委托	客户端使用已有的JWT直接获取访问令牌
令牌流	轮询机制	直接交换	断言式请求
典型应用	智能电视、IoT设备、CLI工具	服务间调用、权限降级、身份联合	机器对机器通信、服务账户、微服务

处理流程

sequenceDiagram participant Client participant WSO2APIM (Authorization Server) participant Keycloak (External IdP) Note over Client, Keycloak: 准备阶段 Client ->> Keycloak: 1. 通过Keycloak认证获取JWT Keycloak -->> Client: 返回JWT（断言） Note over Client, WSO2APIM: JWT Bearer Grant 流程 Client ->> WSO2APIM: 2. 令牌请求 (grant_type=jwt-bearer, assertion=JWT) WSO2APIM ->> WSO2APIM: 3. 验证JWT签名、有效期、颁发者 WSO2APIM ->> WSO2APIM: 4. 提取身份/声明（如sub, aud） WSO2APIM ->> WSO2APIM: 5. 根据JWT中的信息创建会话并颁发自身的访问令牌 WSO2APIM -->> Client: 6. 返回WSO2 APIM的访问令牌

💎 总结与安全考量

选择哪种授权类型完全取决于你的具体应用场景。设备代码授权优化了受限设备的用户体验，令牌交换授权为复杂的服务间信任链提供了灵活性，而JWT持有者授权则是机器对机器通信的简洁高效方案。

在实施这些授权流程时，务必关注以下安全最佳实践：

• 严格控制权限：遵循最小权限原则，只为应用授予其必需的最少权限。
• 验证与监控：服务器端必须严格验证所有令牌和断言（如JWT的签名和有效期），并建立日志审计和异常行为监控机制。
• 保护令牌：访问令牌和刷新令牌是敏感凭证，在传输和存储过程中必须加以保护。

wso2中的实战

wso2 sp的配置

配置认证grant_type类型

keycloak idp的配置

keycloak中为客户端开启roles之后，如果有用户有客户端的角色，会在jwt中多出来aud数组字段，也可以为wso2客户端添加自定义的client scope，然后为它添加aud的cliams

IDP名称必须与IDP中token的Issuer相同

测试

curl -X POST 'https://test-apim.xxx.com/oauth2/token' -H 'Content-Type: application/json' -H 'Content-Type: application/json' -u 'wso2-sp-client-id:wso2-sp-client-secret' --basic -d '{
    "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
    "assertion": "abc.abc.abc",
    "scope": "openid apim:subscribe"
}'

如果keycloak_token过期，就返回这个400错误

{
  "error_description": "JSON Web Token is expired., Expiration Time(ms) : 1769413736000, TimeStamp Skew : 0, Current Time : 1769413748585. JWT Rejected and validation terminated",
  "error": "invalid_grant"
}

如果成功，会返wso2平台的token

{
  "access_token": "8b23bf56-f8d2-33fa-9962-f298a797ce94",
  "refresh_token": "aad2555-30b0-3591-8c70-b2cdc042cc41",
  "scope": "apim:subscribe openid",
  "id_token": "",
  "token_type": "Bearer",
  "expires_in": 3185
}

用户登录成功后，会初始化用户表，需要注意的是，这种urn:ietf:params:oauth:grant-type:jwt-bearer首次登录添加的用户，它位于wso2am_db.idn_auth_user表，user_name同样是三方社区token中的sub字段；而标准oauth的授权码认证后，除了在wso2am_db.idn_auth_user表初始化外，还在wso2am_share_db.um_user表也会添加一份用户数据。