参数:https://datatracker.ietf.org/doc/html/rfc7523
oauth2.0中的三方另类授权
相识OAuth 2.0中特定的授权范例(Grant Type)对于构建安全的认证流程至关告急。下面为你具体先容这三种基于URN声明的扩展授权范例。
🔐 装备代码授权 (urn:ietf:params auth:grant-type:device_code)
这种授权模式专为输入本事受限或没有欣赏器的装备计划,好比智能电视、游戏机、IoT装备或下令行工具(CLI)。
- 工作原理:其核心是一个两步过程。
- 装备获代替码:装备上的应用起首向授权服务器(如 Microsoft Entra ID)的 /devicecode 端点发起哀求。服务器会返回一组信息,包罗一个简短的 user_code(用户代码)和一个 verification_uri(验证网址)。
- 用户授权:装备将 user_code 和 verification_uri 表现给用户,并提示用户在其他装备(如个人手机或电脑)上打开欣赏器,访问该网址并输入代码。用户在授权服务器的正规页面上完成身份验证(大概包罗多因素认证)并同意授权。在此期间,装备应用会定期轮询授权服务器的令牌端点,直到用户完成使用后获取访问令牌和革新令牌。
- 安全风险与防御:必要注意的是,此流程大概被用于举行高迷惑性的网络垂纶攻击(称为“装备代码垂纶”)。攻击者会诱导用户在真实的微软登录页面输入由攻击者天生的装备代码,从而授权一个恶意应用。防御步伐包罗在服务器端严酷限定应用同意战略、实行条件访问战略(如要求来自合规装备),以及对用户举行安全教导。
🔄 令牌交换授权 (urn:ietf:params auth: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 auth:grant-type:jwt-bearer)
这种授权范例允许客户端直接使用一个预先署名的JWT(JSON Web Token)作为断言(assertion)来获取访问令牌。
- 根本流程:客户端向授权服务器的令牌端点发起POST哀求,在哀求体中,grant_type 参数设置为 urn:ietf:params
auth: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 auth:grant-type:jwt-bearer初次登录添加的用户,它位于wso2am_db.idn_auth_user表,user_name同样是三方社区token中的sub字段;而标准oauth的授权码认证后,除了在wso2am_db.idn_auth_user表初始化外,还在wso2am_share_db.um_user表也会添加一份用户数据。
免责声明:如果侵犯了您的权益,请联系站长及时删除侵权内容,谢谢合作!qidao123.com:ToB企服之家,中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |