在 S2S 场景中理解 On-Behalf-Of (OBO) 流程
在现代微服务架构中，服务之间的调用经常涉及到用户身份的传递。On-Behalf-Of (OBO) 授权流是一种常见的方式，用来确保用户的权限在调用链中保持一致。
🔍 什么是 OBO
-
定义：OBO（On-Behalf-Of）是 OAuth2.0 中的一种授权流，允许一个服务在调用下游 API 时，使用用户的身份和权限，而不是服务本身的身份。
-
目的：确保用户的权限和身份在多层服务调用中保持一致。
-
区别：
-
Client Credentials Flow：服务用自己的身份调用下游 API。
-
OBO Flow：服务用用户的身份调用下游 API。
-
⚙️ OBO 流程步骤
-
用户登录：用户在前端应用完成登录，获取 Access Token。
-
调用中间层 API：前端请求中带上用户的 Token。
-
中间层 API 发起 OBO 请求：中间层用用户 Token 向身份平台（如 Azure AD）换取新的 Token。
-
调用下游 API：中间层用新的 Token 调用下游 API。
-
下游 API 验证 Token：确认用户身份和权限，返回数据。
📝 Startup 配置示例
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd")).EnableTokenAcquisitionToCallDownstreamApi().AddInMemoryTokenCaches();builder.Services.AddAuthorization();
- appsettings.json
{"AzureAd": {"Instance": "https://login.microsoftonline.com/","TenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","ClientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","ClientSecret": "your-client-secret","Audience": "api://your-api-app-id"}
}
📊 OBO 的适用场景
-
多层架构：前端 → 中间层 → 下游服务。
-
用户数据访问：下游 API 需要知道调用者是哪个用户。
-
权限传递：确保用户的权限在调用链中不丢失。
🔑 总结
OBO 流程的核心是：中间层 API 不用自己的身份，而是代表用户去访问下游服务。这样可以保证用户的权限链条完整，避免服务“冒充”用户。