从 Scope 到 ABAC：设计支持 OAuth2 的下一代细粒度权限系统

作者： /

在构建现代分布式应用，尤其是面向开放平台、金融科技或企业级 SaaS 时，身份认证与授权是安全体系的基石。OAuth2 的 scope 机制为第三方应用提供了用户授权委托的标准化框架，但它本质上是一种粗粒度的权限声明。本文旨在深入探讨如何超越简单的 scope 字符串匹配，构建一个能够支持复杂业务场景的细粒度权限控制系统，并最终演进到基于属性的访问控制（ABAC）模型，以应对不断变化的业务规则和安全需求。

现象与问题背景

在一个典型的微服务架构中，API 网关通常是权限校验的第一道关卡。当一个携带 OAuth2 Access Token 的请求到达时，网关会进行验签，并解析出其中包含的 scope 列表。例如，一个电商平台的订单服务，其某个接口可能要求调用方具有 order:read 这个 scope。网关的逻辑非常简单：检查 Token 的 scope 列表中是否存在 order:read 字符串。如果存在，请求就被放行到后端的业务服务。

这种模式在初期可以正常工作，但随着业务复杂度的增加，其局限性会迅速暴露：

  • 粒度过粗：order:read 意味着可以读取“所有”订单。但真实需求是：“用户 A 只能读取他自己的订单”、“区域经理可以读取其管辖区域内的所有订单”、“客服人员只能在处理工单时临时读取相关订单”。这些场景无法用一个简单的 scope 字符串来描述。
  • 权限逻辑渗透业务代码：为了实现细粒度控制，开发者不得不在业务服务内部编写大量重复的权限校验逻辑。例如，在订单服务的代码中，会出现大量的 if (requestingUserId.equals(order.getOwnerId())) 这样的判断。这使得权限逻辑与业务逻辑高度耦合，难以维护、审计和变更。
  • 角色爆炸与僵化：为了应对不同的权限组合，系统可能会引入大量静态的角色（Role），例如“普通用户”、“VIP用户”、“区域经理”、“客服主管”等。当权限维度增加时（如按部门、项目、数据敏感级划分），角色的数量会呈指数级增长，导致所谓的“角色爆炸”问题，管理成本极高。

问题的核心在于，我们将 OAuth2 的 scope 错误地等同于了权限（Permission）。Scope 的本意是“范围”或“授权范围”，是用户同意第三方应用代表他执行操作的边界。而权限，则是关于“谁（Subject）能对什么（Resource）做什么（Action）”的精确描述。将这两者混为一谈，是导致后续架构僵化的根源。

关键原理拆解

作为架构师，我们需要回归计算机科学的基础，从访问控制模型的演进历史来理解问题的本质。这部分内容，我会切换到更严谨的学术视角。

访问控制（Access Control）的核心是回答“一个请求是否应该被允许”的问题。主流的访问控制模型包括：

  1. 自主访问控制 (DAC – Discretionary Access Control): 资源的所有者可以决定谁有权访问该资源。类比于 Unix 文件系统的 chmod，文件所有者可以授予其他用户读/写/执行权限。这种模型非常灵活，但在大型组织中难以集中管理和审计。
  2. 强制访问控制 (MAC – Mandatory Access Control): 系统根据固定的安全策略（通常由管理员定义）来强制执行访问控制，用户无法改变。例如，根据安全级别（绝密、机密、公开）来控制对信息的访问。这常见于军事和高安全环境。
  3. 基于角色的访问控制 (RBAC – Role-Based Access Control): 这是目前业界应用最广泛的模型。它在用户（Subject）和权限（Permission）之间引入了“角色”（Role）这一中间层。权限被授予角色，而用户通过被分配一个或多个角色来获得相应的权限。这简化了授权管理：当员工入职或转岗时，只需调整其角色即可。我们前面提到的“角色爆炸”正是 RBAC 在应对高度动态和上下文相关的权限需求时遇到的瓶颈。
  4. 基于属性的访问控制 (ABAC – Attribute-Based Access Control): 这是下一代访问控制模型的核心思想。ABAC 不再依赖静态的角色和权限绑定，而是通过一套策略（Policies）来动态地评估访问请求。策略基于请求的各类“属性”作出决策。这些属性通常分为四类：
    • 主体属性 (Subject Attributes): 关于发起请求的用户的信息，如用户ID、角色、部门、安全等级、年龄等。
    • 资源属性 (Resource Attributes): 关于被访问对象的信息，如资源ID、所有者、创建时间、数据敏感度、所属项目等。
    • 操作属性 (Action Attributes): 用户试图执行的操作，如 read, write, approve, delete。
    • 环境属性 (Environment Attributes): 请求上下文信息，如访问时间、IP地址、设备类型、请求来源地等。

    一条 ABAC 策略可以被描述为：“允许 拥有属性 role:manager 和 department:X 的主体，对属性为 type:expense_report 和 department:X 且 amount < 5000 的资源，在 working_hours 的环境下，执行 approve 操作。” 这种模型的表达能力远超 RBAC，能够完美应对前文提到的细粒度控制场景。

因此，我们的架构目标变得清晰：将 OAuth2 的 scope 作为触发授权流程的“意图声明”和粗粒度门禁，而在系统内部，构建一个基于 ABAC 的策略引擎来执行真正的、上下文感知的细粒度权限决策。

系统架构总览

要实现上述目标，我们需要设计一个解耦的、中心化的权限决策体系。整个系统由以下几个关键组件构成，它们共同遵循 XACML（可扩展访问控制标记语言）定义的标准模型，即使我们不直接使用 XACML，其思想也是通用的。

  • 策略执行点 (PEP - Policy Enforcement Point): 这是权限逻辑的执行者，通常内嵌在 API 网关、服务网格的 Sidecar 或业务服务的库中。它负责拦截所有业务请求，从请求中提取主体、资源、操作等信息，然后向 PDP 发起决策请求。它从不自己做决策，只负责执行 PDP 的裁决（Permit/Deny）。
  • 策略决策点 (PDP - Policy Decision Point): 这是权限体系的大脑。它接收来自 PEP 的决策请求，根据预先配置的策略集（Policies）进行评估，并返回最终的决策结果。PDP 是无状态的，它只关心输入的属性和策略规则。
  • 策略管理点 (PAP - Policy Administration Point): 这是策略的创建、管理和分发中心。管理员或开发者通过 PAP 定义和更新 ABAC 策略。这些策略随后会被加载到 PDP 中。
  • 策略信息点 (PIP - Policy Information Point): PDP 在决策时可能需要一些请求中未直接包含的属性。例如，决策需要知道订单的归属部门，但 API 请求中只有订单 ID。PIP 的作用就是作为 PDP 的数据源，根据需要实时或准实时地从外部系统（如数据库、LDAP、HR系统）获取额外的属性信息。
  • 授权服务器 (Authorization Server): 依然是标准的 OAuth2 组件，负责用户认证和颁发 Access Token。我们的改造点在于，让它在 Token 的 claims 中携带更丰富的主体属性（如用户ID、角色、部门等），以减少 PIP 的查询压力。

整个请求流程如下：客户端携带 Access Token 访问 API 网关（PEP）。网关验证 Token 有效性并解析出 scope 和 claims。网关将请求信息（HTTP方法、路径）和 Token 中的主体属性打包，发送给 PDP。PDP 根据策略进行评估，如果需要额外信息，它会通过 PIP 查询。最终 PDP 返回“允许”或“拒绝”的决策。网关根据决策结果，选择将请求转发给后端服务，或直接返回 403 Forbidden。

核心模块设计与实现

现在，让我们切换到极客工程师的视角，深入到代码和实现细节中。

1. Access Token (JWT) 的设计

不要再把 Access Token 当成一个只含 scope 的简单凭证。我们应该使用 JWT (JSON Web Token)，并充分利用其 payload (claims) 来传递丰富的“主体属性”。这是一种典型的空间换时间优化，将高频读取的用户属性嵌入 Token，避免每次请求都去数据库查询。


{
  "iss": "https://auth.mycompany.com",
  "sub": "user-12345",
  "aud": "order-service-api",
  "exp": 1678886400,
  "iat": 1678882800,
  "jti": "a-unique-jwt-id",
  "scope": "order:read order:write",
  "ext": {
    "roles": ["customer", "vip_gold"],
    "department_id": "D101",
    "region": "US-WEST"
  }
}

在这个 JWT 示例中，除了标准的 OAuth2 字段，我们在自定义的 ext (extensions) 字段中加入了用户的角色、部门、区域等属性。API 网关（PEP）可以直接从 Token 中解析这些属性，而无需查询 PIP，极大地提升了性能。一个坑点：JWT 的大小是有限制的，通常 HTTP Header 的大小限制在 8KB 左右。不要试图把用户的所有信息都塞进去，只放那些在权限决策中高频使用的、相对稳定的属性。

2. 策略引擎 (PDP) 的选型与实现

自己从头写一个高效、安全的策略引擎是极其复杂的工作。强烈建议使用成熟的开源方案，其中 Open Policy Agent (OPA) 是当前的事实标准。OPA 使用一种名为 Rego 的声明式语言来编写策略，非常适合表达复杂的 ABAC 规则。

OPA 可以作为独立的微服务部署，PEP 通过 HTTP API 与之通信。下面是一个 Rego 策略示例，用于实现“用户只能读取自己的订单”：


package http.authz

import input.request.path
import input.request.method
import input.token.payload.sub

# 默认拒绝
default allow = false

# 规则：允许读取订单
allow {
    # 匹配HTTP方法和路径
    method == "GET"
    path_matches_order_details(path)

    # 从路径中提取orderId
    order_id := path[2]

    # 通过PIP获取订单的拥有者 (这是关键)
    order_owner_id := data.pip.orders[order_id].owner_id

    # 决策：请求者的用户ID必须等于订单的拥有者ID
    sub == order_owner_id
}

# 辅助函数，用于路径匹配
path_matches_order_details(path) {
    path[0] == "api"
    path[1] == "orders"
    count(path) == 3
}

在这个策略中，input 是 PEP 传递给 OPA 的 JSON 对象，包含了请求的所有上下文。data.pip.orders 则代表 OPA 通过 PIP 获取的外部数据。这个策略清晰地将“谁（input.token.payload.sub）”、“做什么（GET）”、“什么资源（/api/orders/{order_id}）”以及资源的属性（owner_id）关联了起来。

3. API 网关 (PEP) 与 OPA 的集成

API 网关（如 Spring Cloud Gateway, Kong, Envoy）需要与 OPA 集成。集成逻辑通常是一个自定义的 filter 或 middleware。


// 伪代码，展示在API Gateway中的集成逻辑
func opaAuthzFilter(request *http.Request) (bool, error) {
    // 1. 验证并解析JWT
    claims, err := validateAndParseJWT(request.Header.Get("Authorization"))
    if err != nil {
        return false, err // 401 Unauthorized
    }

    // 2. 构建发送给OPA的input对象
    opaInput := map[string]interface{}{
        "request": map[string]interface{}{
            "method": request.Method,
            "path":   strings.Split(strings.Trim(request.URL.Path, "/"), "/"),
            "query":  request.URL.Query(),
        },
        "token": map[string]interface{}{
            "payload": claims,
        },
    }

    // 3. 调用OPA决策API
    // 这里的URL是OPA的RESTful API，查询我们上面定义的 allow 规则
    opaQueryURL := "http://opa.service:8181/v1/data/http/authz/allow"
    reqBody, _ := json.Marshal(opaInput)
    resp, err := http.Post(opaQueryURL, "application/json", bytes.NewBuffer(reqBody))
    // ... 错误处理 ...

    var opaResult struct {
        Result bool `json:"result"`
    }
    json.NewDecoder(resp.Body).Decode(&opaResult)

    // 4. 根据OPA的决策执行
    return opaResult.Result, nil // true for Permit, false for Deny (403 Forbidden)
}

这段伪代码展示了 PEP 的核心职责：上下文构建 和 决策委托。它自身不包含任何业务权限逻辑，只是一个忠实的执行者。

性能优化与高可用设计

引入中心化的权限决策体系，最大的挑战就是性能和可用性。每一次 API 调用都可能增加一次到 PDP 的网络往返，以及多次到 PIP 的数据查询。这可能成为整个系统的性能瓶颈和单点故障。

  • PDP 部署模式的权衡：
    • 中心化服务：将 OPA 部署为一个独立的服务集群。优点是易于管理、维护和监控。缺点是每次决策都有网络开销。
    • Sidecar 模式：将 OPA 作为一个 sidecar 容器与每个需要权限校验的服务（或网关实例）部署在一起。决策请求通过 a `localhost` 调用，网络延迟几乎为零。缺点是资源消耗增加，运维复杂度更高。对于性能极度敏感的核心交易链路，Sidecar 模式是更优选择。
  • PIP 性能是关键：PIP 每次查询外部数据源（如数据库）都是昂贵的。必须引入多级缓存。
    • OPA 内置缓存：OPA 支持将数据预加载到内存中（Bundle 机制），并定期刷新。对于变化不频繁的数据（如用户角色、组织架构），这是首选方案。
    • 外部分布式缓存：在 PIP 服务和底层数据源之间增加一层 Redis 或 Memcached。对于需要频繁查询的资源属性（如订单所有者），这至关重要。你需要仔细设计缓存键和失效策略，避免脏数据导致错误的权限判断。
  • 高可用与容灾策略：
    • PDP/PIP 集群化：所有权限相关的服务都必须是无状态且可水平扩展的，部署多个实例并进行负载均衡。
    • Fail-Open vs. Fail-Close：这是一个关键的安全决策。当 PDP 服务不可用时，PEP 应该怎么做？Fail-Close（默认拒绝所有请求）是最安全的选择，但会牺牲可用性。Fail-Open（默认允许所有请求）会保证业务连续性，但带来巨大的安全风险。对于金融或敏感数据系统，必须选择 Fail-Close。对于非核心业务，可以考虑降级策略，例如允许读请求，拒绝写请求，或者使用上次缓存的决策结果（带TTL）。

架构演进与落地路径

全盘切换到一套复杂的 ABAC 系统对于一个已经在线上运行的庞大系统来说，是不现实的。一个务实的演进路径至关重要。

  1. 第一阶段：增强型 RBAC (RBAC with Claims)。

    维持现有的基于 scope 的粗粒度校验。同时，开始在 JWT 中添加自定义 claims，如角色、部门等。在业务代码中，逐步用读取 claims 的方式替代直接查询数据库。这一步的目标是让“主体属性”开始流通起来，并为后续改造打下基础。

  2. 第二阶段：引入中心化 PDP (影子模式与逐步放量)。

    部署 OPA 集群，并集成到 API 网关。初期可以采用“影子模式”（Shadow Mode），即 PEP 调用 PDP 进行决策，但只记录决策结果，并不实际执行拦截。这样可以在不影响线上业务的情况下，验证策略的正确性和性能。当策略覆盖率和准确率达到要求后，首先针对新业务或非核心业务开启强制执行，逐步扩大范围。

  3. 第三阶段：构建 PIP 并丰富策略维度。

    开发独立的 PIP 服务，并实现高效的缓存机制。开始编写更复杂的 ABAC 策略，引入资源属性和环境属性。例如，为财务系统上线基于审批金额和发起人级别的动态审批流策略。这个阶段是真正发挥 ABAC 威力的时候。

  4. 第四阶段：全面推广与赋能。

    为业务团队、安全团队和产品经理提供可视化的 PAP（策略管理平台），让他们能够以更友好的方式（甚至自然语言）管理权限策略。此时，权限管理已经从开发人员的编码任务，转变为安全和业务策略的配置任务，实现了真正的“策略即代码”与业务安全解耦。架构的最终价值得以体现。

从简单的 OAuth2 scope 校验，到构建一套完整的、基于 ABAC 的细粒度权限控制系统，是一次深刻的架构升级。它不仅仅是技术的替换，更是将权限管理从分散、隐式的业务代码中剥离出来，提升为一种显式的、可集中管控的核心服务能力。这条路虽然充满挑战，但它将为你的系统带来长期的可维护性、灵活性和安全性，是构建企业级复杂应用的必经之路。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部