授权定义了经过身份验证的用户可以执行的操作。 [身份验证0]确认身份，而授权则控制对资源和操作的访问。本指南介绍了构建强大的权限系统的模板、实现和最佳实践。
身份验证与授权
身份验证
回答：“你是谁？”通过凭据验证身份。
授权
回答：“你能做什么？”。身份确认后确定权限。
实际例子
用户登录（[身份验证1]）。系统检查您是否可以访问管理面板（授权）。
为什么授权很重要
如果没有适当的访问控制，任何经过身份验证的用户都可以访问任何资源。敏感数据被暴露，破坏性行为变得可能。授权保护关键数据和操作。
访问控制模型
ACL（访问控制列表）
定义谁可以访问每个资源的列表。简单，但不能很好地扩展到复杂的系统。
RBAC（基于角色的访问控制）
权限分配给角色，角色分配给用户。层次结构。最常见的型号。
ABAC（基于属性的访问控制）
基于属性的决策：用户、资源、环境。灵活但复杂。
ReBAC（基于关系的访问控制）
基于实体之间的关系。 “如果你拥有它，你就可以编辑它。”由桑给巴尔 (Google) 使用。
RBAC 详细信息
组件
- 用户： 访问的人或系统。
- 角色： 权限集（管理员、编辑者、查看者）。
- 权限： 允许的操作（创建、读取、更新、删除）。
- 功能： 受保护的对象（帖子、用户、设置）。
角色层次结构
角色可以继承其他角色。 Admin继承自Editor，Editor继承自Viewer。减少重复。
结构示例
| 滚动 | 权限 | 范围 |
|---|---|---|
| 管理员 | 创建、读取、更新、删除 | 所有资源 |
| 编辑 | 创建、读取、更新 | 内容 |
| 观众 | 阅读 | 公开内容 |
RBAC 实现
数据库
用户、角色、权限和关系表（user_roles、role_permissions）。
验证中间件
在执行操作之前，中间件会检查用户是否具有所需的权限。
装饰者/守卫
在现代框架中，保护路由或方法的注释。
权限缓存
避免就每个请求咨询银行。将用户权限缓存在Token或者Redis中。
ABAC：高级灵活性
何时使用
当 RBAC 表达能力不够时。规则取决于动态上下文。
政策示例
- 如果您是文档的作者，则可以编辑。
- 如果您在同一部门，则可以访问它。
- 如果金额低于您的限额，您可以批准。
###XACML
表达 ABAC 政策的标准。基于 XML，用于企业环境。
资源级别权限
行级安全性
由注册表控制。用户只能看到自己的数据。原生支持 PostgreSQL。
列级安全性
现场控制。某些字段仅对某些角色可见。
多租户
租户之间的隔离。每个组织只能访问其数据。
操作系统权限
iOS
访问相机、位置、照片需要用户的明确许可。 Info.plist 定义描述。
###安卓
清单中声明的权限。危险权限需要运行时同意。
良好实践
- 使用时订购，而不是预先订购。
- 解释你为什么需要它。
- 如果被拒绝，请优雅地奔跑。
代币和声明
智威汤逊声明
令牌可以包含权限声明。服务器无需咨询银行即可进行验证。
OAuth 中的范围
它们定义令牌可以访问哪些资源。读：用户，写：帖子。
护理
大令牌会影响性能。平衡在线索赔与咨询。
API 中的授权
端点验证
每个端点在执行之前都会检查特定的权限。
资源服务器
API 服务器验证令牌并根据范围和声明进行授权。
政策决策点 (PDP)
决定授权的集中服务。开放策略代理 (OPA) 就是一个例子。
实现模式
默认拒绝
除非明确允许，否则拒绝访问。故障安全。
最低权限
授予最低限度的必要费用。用户只能得到他们需要的东西。
职责分离
关键任务需要多人参与。没有人能独自完成所有事情。
审计和日志记录
记录决定
记录谁试图访问什么以及是否被允许或拒绝。
异常检测
可疑模式：多次拒绝、下班后访问、权限升级。
合规性
法规要求审计跟踪。 GDPR、SOX、HIPAA。
常见错误
仅在前端验证
后端应该经常检查。前端是可操纵的。
角色硬编码
它使进化变得困难。使用灵活的配置。
权限过多
为了方便起见，请提供不必要的访问权限。最小特权原则。
缺乏测试
未经充分测试的权限会产生漏洞。测试访问场景。
工具和库
卡斯宾
支持多种模型（RBAC、ABAC、ACL）的授权库。
开放策略代理 (OPA)
政策引擎。授权决策作为代码。
Auth0 FGA
细粒度授权。模型类似于Google的Zanzibar。
奥利酮
受桑给巴尔启发的开源实现。
多租户和授权
隔离
租户不会访问彼此的数据。检查所有查询。
租户角色
用户可以在不同的组织中担任不同的角色。
超级管理员
平台操作的跨租户访问。请务必谨慎使用。
结论
实施良好的授权可以保护数据并确保用户只做他们应该做的事情。选择合适的模型（大多数为 RBAC），默认实施拒绝，彻底测试并审核访问。安全性是一个持续的过程，而不是一次性配置。
##常见问题解答
1) RBAC 对于大多数情况来说足够了吗？ 是的。 RBAC 可以很好地服务于大多数应用程序。 ABAC适用于更复杂的场景。
2) 在哪里存储权限？ 事实来源数据库。缓存（JWT 声称，Redis）以提高性能。
3) 权限被拒绝如何处理？ 返回 403 Forbidden 并带有通用消息。不要透露政策细节。
4) 我需要单独的授权服务吗？ 对于大型系统来说，这可能是值得的。对于较小的应用程序，集成库就足够了。
5) 如何测试授权？ 按角色/权限检查允许和拒绝的访问的自动化测试。
另请阅读
- 【授权与权限-最佳实践基础知识2
- [授权和权限：防止未经授权的访问的最佳实践3
- [应用程序身份验证：完整的安全性和用户体验指南4
- 【Deno简介：现代开发实用指南5
- [云原生安全：保护 Kubernetes 基础设施6
- [Next.js 中的服务器操作：无需为此维护 API 的突变7