在 S2S 场景中理解 On-Behalf-Of (OBO) 流程

在 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 不用自己的身份，而是代表用户去访问下游服务。这样可以保证用户的权限链条完整，避免服务“冒充”用户。