认证已解决，授权才是难题
Authentication Is Largely Solved. Authorization Isn't
我的新书《Authorization in Action》已出版。过去二十年，我专注于解决“你是谁”的问题，如今认证技术如 passkeys 和 FIDO 已相当成熟。但真正的挑战在于“你能做什么”。授权逻辑往往散落在应用代码中，被反复拙劣地重写。随着 AI agents 开始代表人类行动，明确它们的行为边界变得至关重要。如果无法精确界定代理的权限，我们只能在无用的工具与盲目信任之间做选择。本书通过虚构公司 ACME 的案例，探讨如何构建基于策略的授权系统，让安全与易用性不再对立。
认证只是让你进门，但它无法告诉你能进入哪些房间、能带走什么，甚至无法确认派你来的人是否有权这么做。
HN 评论区
13- zzo38computer
总的来说，认证和授权都还没被很好地解决，尽管在某些特定场景下它们已部分得到解决。
对于单机环境，我认为基于能力（capability-based）的安全机制配合代理能力（proxy capabilities）对两者都有帮助。但这单靠它还不够；你可以引入用户账户数据库，并处理由这种基于能力的安全机制衍生出的权限。这种方式很灵活，因为每个进程可以拥有不同的权限，而借助代理能力，权限所能执行的操作也可以超出固定的权限集合。
对于多机环境，我认为 X.509 证书链对两者都有帮助。你可以验证用户是否使用终端证书中的密钥进行认证，并检查证书链中是否存在受信任的权威机构，从而了解其拥有的权限。随后，根据权限类型（例如，扩展密钥用法可能仅需终端证书具备，而允许访问哪些文件以及如何访问这类权限则必须由整个证书链共同授予），检查所需权限是由包含终端证书在内的整条链授予，还是仅由终端证书授予。你还可以添加扩展项，以指定你的应用所需的认证和/或授权的任何额外细节。（使用 X.509 证书链也意味着你不再需要 API 密钥或密码（p […]）
- kerblang
除非你想花几个小时去调试 YAML 和 JSON 数据块及模板，在验证上苦苦挣扎，更糟糕的是把应用超级用户的工作转嫁给开发者和管理员，否则我绝不会把授权逻辑迁移到 AWS。（编辑：还忘了核心功能的锁定问题，一旦切换云厂商就得重做）
相比之下，如果你构建得当，提供一个让受信任用户能为下级人员分配权限的用户界面，优势是巨大的。你确实需要实现细粒度控制，能够将权限集汇总成预定义的角色，并且——这是一个许多人忽略的简单事项——允许给单个用户分配多个角色。正如人们常说的，用户经常“身兼数职”，你必须考虑到这一点。
- VCFundedGenYer
这篇文章纯属废话。
实际上，从运营角度看，这些问题一个都没解决。每个网站、应用或平台的登录处理方式都不同。有些还在用短信 2FA，有些还在用密码，有些错误地实现了 passkeys，有些在用基于应用的多因素认证，有些在用魔法链接，有些在用邮箱验证码。
当现状变得比以往任何时候都更复杂，且用户体验糟糕透顶（passkeys，咳咳）时，你没法一本正经地说这问题已经“解决”了。