别再登录了：授权而非认证
Authorize, don't authenticate
传统的网页应用总让你先登录认证，证明身份后才能访问数据，但这意味着你的数据被应用方掌控。我主张一种新范式：授权而非认证。通过 my project ayb，应用不再需要登录界面，而是请求访问你掌控的个人数据库。你可以像创建文档一样轻松创建数据库，应用通过 OAuth2 协议获取访问令牌，所有数据都存储在你自己的数据库中，而非应用服务器上。这种模式让你真正拥有数据主权，随时可撤销应用权限，避免数据被删除、出售或泄露。虽然目前主要适用于个人数据，但在协作和社交数据领域，这种分离应用与数据库的思路仍值得探索。
你的数据！你不必向任何人证明你有权访问它，也不该有人告诉你如何使用自己的数据。
HN 评论区
38- jdub
被这个话题吸引了，不过这里对 authentication 和 authorization 的用法似乎有些名不副实，核心议题其实是数据所有权。
表面上看，拥有数据所有权的概念很有道理，而且不同提供商/应用之间也确实存在零散的支持。
但让用户自己维护一个数据库，然后授权给服务使用，这个具体想法极不切实际。它或许能在高度受控的环境里用于实验，但绝无法扩展。
1. 数据库需要维护、备份和故障转移
2. Schema 更新简直是噩梦。没人乐意干这事，尤其是规模越大越如此。
3. 这里的 authorization 似乎遵循一对多模式，即一个数据库对应多个应用。一旦涉及更新操作，这就行不通了。
- sandeepkd
1. 性能问题怎么解决？如果我有一个复杂的 join，而你的数据库很慢，或者你的连接不稳定，我该怎么在我这边排查问题？
2. 是什么能阻止我（或任何攻击者）利用你的安全漏洞？你真的 100% 确定自己是安全的吗？
3. 你提到了协作——在公司层面这该怎么运作？如果我们有大量用户且需要控制访问权限，而公司才是拥有数据权利的实体呢？
- pakl
太多工具和库把 authorization 和 authentication 混在一起了，很难找到一个能让你外包身份验证的 authorization server。
（“auth”这个缩写经常被用来笼统地指代两者，而且定义往往不够明确。）
无耻插播广告：我和同事实现了一个极简的 authorization server，让你可以利用自己信任的身份提供商（比如 Entra ID 甚至 Auth0/Okta）并处理授权。它会查询已识别用户应拥有或授予的角色和权限，并颁发包含这些授权信息的 token。