Recommendation

把核心权限模型保留在应用域内;身份平台只负责稳定的身份与组织上下文。

认证证明用户是谁;授权决定用户能做什么。先画出资源与操作边界。123

适用范围: Teams moving beyond a small, stable set of application roles

Main trade-off

应用自有模型可迁移且贴近业务,但需要团队承担策略维护和审计责任。123

没有单一默认方案的原因: Authorization expresses product-specific rules. Relationship depth, policy authorship, latency, auditability, and operational ownership determine the architecture, so a universal product default would hide the real decision.

选择标准

按真实约束逐项判断,不要只比较功能列表。

  1. Policy complexity

    Distinguish stable role checks from contextual, attribute-based, or relationship-based rules.34

  2. Evaluation boundary

    Decide whether checks run in application code, a local service, or a remote managed service.12

  3. Policy authorship

    Identify whether only engineers or also security and customer administrators must change policy.1

  4. Audit and scale

    Estimate decision volume, consistency needs, explainability, and evidence requirements.123

适用路线

这些条件会改变默认答案;请在作出承诺前逐项验证。

Keep authorization application-owned

Start with explicit application checks and a small role or permission model.

This keeps the system legible while policy is still compact and product-specific.

Verify: Revisit when permissions become cross-service, customer-configurable, or difficult to audit.4

Managed policy administration

Evaluate Permit.io.

A managed control plane can reduce the work of policy administration and productized authorization.

Verify: Do not outsource unclear domain modeling; the application still owns resource and action semantics.1

Local policy decision point

Evaluate Cerbos.

A separate policy engine with local deployment suits teams that want policy separation without a remote check on every request.

Verify: The team still owns deployment, policy rollout, and integration discipline.2

Relationship-based access graph

Evaluate OpenFGA.

Graph-shaped ownership and sharing rules map naturally to relationship-based authorization.

Verify: Avoid adopting graph complexity for a simple role matrix.3

官方资源

官方文档与继续决策的正式路径。

来源

支撑页面关键主张的资料。

  1. 1
    Permit.io documentation

    Permit.io · Accessed Official

  2. 2
    Cerbos documentation

    Cerbos · Accessed Official

  3. 3
    OpenFGA concepts

    OpenFGA · Accessed Official

  4. 4
    NIST RBAC model

    NIST · Accessed Official