starter.wiki中文

Identity

Authorization

Choose where application permissions are modeled, evaluated, and audited.

Recommendation

Choose the policy model before the product.

Application-owned checks, a managed control plane, a local policy decision point, and a relationship graph serve different authorization shapes.123

For: Teams moving beyond a small, stable set of application roles

Main trade-off

External systems separate policy evaluation and administration from application enforcement, while adding modeling, integration, and operating boundaries.123

Why there is no single default: 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.

Decision criteria

Start with the shape and ownership of policy, not the vendor list.

  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

Authorization routes

Each route represents a materially different ownership and modeling choice.

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

Official resources

Use product documentation and the NIST RBAC material to compare models and boundaries.

DocumentationOpenFGA concepts

Starter stacks

Sources

Primary sources supporting the route definitions.

  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