身份验证是知道“你是谁”。 授权就是知道“你能做什么”。
许多开发人员混淆了两者。您已登录系统（身份验证正常），但您可以删除[数据库6吗？或者看看CEO的薪水？这就是授权。
管理权限是应用程序安全性中最关键的部分。这里的一个缺陷（访问控制损坏）是 OWASP 排名中排名第一的漏洞。
在本文中，我们将介绍实现强大的权限系统的基础知识和最佳实践。
访问控制模型
有多种方法可以对用户说“是”或“否”。
1.RBAC（基于角色的访问控制）
最常见的。您创建“角色”。
- 管理员：你可以做任何事情。
- 编辑：可以创建和编辑帖子。
- 读者：您可以阅读。 您将角色分配给用户 (0)。代码检查：1。
- 优点：易于理解和实施。
- 缺点：它是刚性的。如果我希望特定编辑能够删除帖子，但只能删除他自己的帖子，该怎么办？
2.ABAC（基于属性的访问控制）
更细化、更强大。它基于属性。 *“允许编辑 IF (user.id == post.author_id) AND (时间 < 18:00)”。
- 优点：无限的灵活性。
- 缺点：实现复杂性。
3.PBAC（基于策略的访问控制）
用自然语言或单独的代码定义策略。
- 示例：AWS IAM 策略。
最小权限原则
这是黄金法则： 仅授予用户完成工作所需的最低权限。不多也不少。
- 如果某个服务只需要读取数据，则不要授予其写入权限。
- 如果开发人员只需要查看日志，则不要授予对生产数据库的访问权限。
这减少了“攻击面”。如果该用户的帐户被黑客入侵，造成的损失是有限的。
在哪里检查授权？
始终在后端。 如果用户不是管理员，许多现代应用程序会隐藏前端的“删除”按钮。这只是用户体验，而不是安全。 攻击者可以直接调用API2。 后端必须检查每个请求的权限。
IDOR（不安全的直接对象引用）
经典的失败。 网址为3。我看到了我的发票。 我将 URL 更改为 4。我看到了邻居的账单。 这是伊多尔。 更正：后端应检查：“登录用户是否是发票 101 的所有者？”。如果不是，则返回 403 Forbidden。
结论
授权不是最后添加的东西。它必须在[数据库8]和API的架构中进行设计。使用成熟的库（如 JS 或 Pundit 中的 CASL），而不是用分散的 5 来弄乱你的代码。安全就是控制。
另请阅读
- [应用程序中的授权和权限：安全访问控制9
- [授权和权限：防止未经授权的访问的最佳实践10
- 【Deno简介：现代开发实用指南11
- [云原生安全：保护 Kubernetes 基础设施12
- [应用程序中的身份验证 - 使用清单的最佳实践13
- [应用程序身份验证：完整的安全性和用户体验指南14