任务决策
授权:让权限模型属于你的产品,而不是某个登录组件
确定角色、资源权限、访问边界与审计规则在何处建模和执行。
Recommendation
把核心权限模型保留在应用域内;身份平台只负责稳定的身份与组织上下文。
认证证明用户是谁;授权决定用户能做什么。先画出资源与操作边界。123
适用范围: Teams moving beyond a small, stable set of application roles
没有单一默认方案的原因: 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.
选择标准
按真实约束逐项判断,不要只比较功能列表。
Policy authorship
Identify whether only engineers or also security and customer administrators must change policy.1
适用路线
这些条件会改变默认答案;请在作出承诺前逐项验证。
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
官方资源
官方文档与继续决策的正式路径。
来源
支撑页面关键主张的资料。
- 1Permit.io documentation
Permit.io · Accessed Official
- 2Cerbos documentation
Cerbos · Accessed Official
- 3OpenFGA concepts
OpenFGA · Accessed Official
- 4NIST RBAC model
NIST · Accessed Official