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

• 设备获取代码：设备上的应用首先向授权服务器（如 Microsoft Entra ID）的/devicecode端点发起请求。服务器会返回一组信息，包括一个简短的user_code（用户代码）和一个verification_uri（验证网址）。
• 用户授权：设备将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）更窄、专用于访问另一个特定微服务的令牌。

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

💎 总结与安全考量

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

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

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

wso2中的实战

wso2 sp的配置

Keycloak中客户端授权范围wso2-role中，添加aud的硬编码

配置认证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": "apim:subscribe"
}'

scope参数如果不传，默认是default，对于apim的开发者平台，这个值必须传，否则无权限添加应用和订阅api

这块功能scope使用你认证能数里的scope，还是使用默认的default，主要在IDP的Claim Configuration配置中进行设置，如图：

如果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，需要注意这个返回值里scope，如果它是default，那是没有操作application的权限的

{
"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表也会添加一份用户数据。

【添加的用户没有订阅者角色，导致用户建立的应用无法订阅API】

• 对于上面的um_user中的用户，它在carbon平台是可以查询到的，它默认是没有subscribe权限的，只有everyone权限
• 这时，它建立的应用，应用是无法订阅api的，我们需要同时为um_user的用户初始化角色subscribe
• 这块功能由product-is系统提供，所以在共享库wso2am_shared_db里，数据表为um_hybrid_role和um_hybrid_user_role。
• 调整源码cargin-apimgt项目org.wso2.carbon.apimgt.impl.issuers.configureForJWTGrantOrExchangeGrant()方法
• 再执行FederatedUserSyncUtil.syncFederatedUserToUMUser(tenantDomain, userName)方法，为期添加初始化um_hybrid_user_role的脚本