授权，而非认证

# 授权，而非认证 来源：https://blog.marcua.net/2026/07/31/authorize-dont-authenticate.html 任何 Web 应用的登录界面，本质上是该应用在对你说："为了访问 *我的* 数据库里 *你的* 数据，请证明你确实是你声称的那个人。" 你在与应用进行**认证**，以便获得向它交出数据的特权。 在之前的一篇博客文章（https://blog.marcua.net/2025/01/05/maintaining-control-of-our-data-with-personal-databases）中，我讨论了应用控制你数据的弊端。应用的所有者可以限制你访问自己的数据。他们可以删除数据。他们可以把数据卖给第三方。他们可能引入一个让其他人能够访问数据的 bug。他们可能被入侵。或者，他们可以不做这些，但日后修改政策，或者经历所有权或管理层的变更。 一言以蔽之：一派胡言。这是你的数据！你不应该为了访问它而向任何人证明你的权利。没有人应该规定你如何使用自己的数据。也没有人应该用你的数据做任何你不舒服的事情。 要重新掌控你的数据，你必须掌控存放数据的数据库¹（https://blog.marcua.net/2026/07/31/authorize-dont-authenticate.html#fn:3）。如果你拥有数据库，你就真正拥有了数据。但运行一个数据库是一项严肃的工程，我们不能指望普通互联网用户都能做到。而且，即使你运行个人数据库，应用应该如何与它交互呢？ 在过去的几个月里，我探索了**个人数据库授权**的概念，它允许你授予某个应用访问你所控制的数据库的权限。具体来说，我在 **ayb**（https://github.com/marcua/ayb）中构建了一个授权流程——这是我的项目，旨在让创建数据库、与协作者共享以及从任何地方查询数据库变得简单。下面是一个视频，展示了如何授予一个应用访问你拥有的全新数据库的权限。关键的是，这个应用没有登录界面，而是请求一个数据库，让你的数据存放在其中： 授权实战：一个没有登录界面的待办事项应用，请求访问你所控制的数据库。 Todos（https://marcua.net/minitools/todos/）是我创建并作为日常主力使用的待办事项应用。 ## 牢牢掌握你的数据 以下是视频背后所发生事情的三个原则： **授权，而非认证。** 在传统 Web 应用中，你与应用进行*认证*，以登录/证明你的身份。只有当你通过密码/通行密钥/... 证明了自己，才能访问你的数据。这使应用掌管了你的数据。相反，你应该*授权*一个应用访问你的个人数据库。在视频中，你会看到 Todos（https://marcua.net/minitools/todos/）要求你*连接你的数据库*（"授权我吧！"），而不是*输入你的密码*（"证明你自己！"）。支持这种流程的技术已经非常成熟且被广泛使用：Todos 发起了 OAuth2（https://en.wikipedia.org/wiki/OAuth#OAuth_2.0）流程，向 ayb 请求一个用于查询数据库的令牌。我开源了一个 **ayb.js 库**（https://github.com/marcua/ayb#javascript-client-library），它代表应用管理这些 OAuth2 交互，工程师可以在不到一个小时内将其集成到新应用中。 **创建数据库应该像创建文档一样简单。** 大多数用户都能打开 Microsoft Word 或 Google Drive 创建一个空白文档。另一方面，大多数用户不知道如何搭建一个 Postgres 数据库，既能定期备份，又能连接到运行中的应用。在视频中，授权流程允许你选择现有数据库或创建一个新数据库，而创建新数据库就像给它起个名字一样简单。如果你创建了一个数据库，你无需任何配置就会收到定期快照/备份，应用也知道如何与 ayb 通信、运行迁移并将数据存储在其中。数据库创建流程的难度不高于在电脑或云端创建文件的流程，这比当今大多数数据库所做到的要多得多。 **应用应在用户数据库之外存储尽可能少的数据。** 视频中的 Todos 应用是静态的 HTML、CSS 和 JavaScript。它对访客一无所知。我猜想在服务器日志的某处可以找到下载该静态资源的任何人的 IP 地址，但除此之外，应用不会在我的服务器上存储任何状态。为了增强隐私，你可以下载一个自包含的 `index.html` 文件并自行托管该应用。当你首次加载 Todos 时，它会要求你*连接你的数据库以开始使用*。一旦它获得了查询你数据库的令牌²（https://blog.marcua.net/2026/07/31/authorize-dont-authenticate.html#fn:2），你所有私密的待办事项条目都存储在你拥有的那个数据库中。你可以随时撤销 Todos 的访问权限。 ## 信任你的托管方 刚刚赞美了将数据存储在你控制的数据库中的种种好处，我不得不稍微泼点冷水。到目前为止，我实际上是在说："不要把你的数据存储在别人那里，把它存储在一个叫 ayb 的东西里。" ayb 是开源的，虽然*你可以*自行托管它（https://github.com/marcua/ayb#running-a-server），但你想这么做吗？我相信 ayb 的安装和运行相当容易，但我当然不认为每个用户都应该成为数据库管理员。这给用户留下了一个令人沮丧的选择：把对第三方应用的信任，换成对第三方数据库托管方的信任。我们是否只是在用一种中心化形式换取另一种中心化形式？ 我认为，将应用与其操作的数据库分开仍然有好处。首先，你实际上有了选择：你不必隐式地接受每个应用开发者都是你数据某一部分的保管者，而是可以一次性选择你的数据存放在哪里，无论你使用多少应用。这种抽象意味着，一旦你掌握了 ayb 这样的工具，你就可以将它用于多个应用，这有望摊薄重新获得数据主动权所需的成本。你可以选择谁来托管你的数据，因为 ayb 是开源的。我梦想有一天，合作社和组织如果希望让用户对其数据拥有主动权，可以提供除自行托管之外的替代方案，并竞争成为你数据的保管者。最后，ayb 不会发明文件格式：你的数据存储在枯燥、广泛接受的文件格式中，如 SQLite 和 DuckDB 的格式³（https://blog.marcua.net/2026/07/31/authorize-dont-authenticate.html#fn:1）。我计划很快添加导出和导入端点，以便更容易带着你的数据离开并迁移到另一个托管方。 ## 超越个人数据：协作与社交互动 "授权，而非认证"模式在明确"拥有"数据的情况中最为顺畅。数据集越是协作或社交互动产物，"谁拥有数据"就越不清晰，授权访问也就越困难。 协作是"个人数据"定义较为模糊的地方之一。如果你独自处理一份文档，很容易告诉应用把"我的文档"存储到"我的数据库"中。但如果你使用像 Google Docs 这样的协作文档编辑工具，与其他人一起处理一份文档，把该文档存储到"个人数据库"意味着什么？ayb 允许你与协作者共享数据库，但每个数据库仍然有一个所有者。探索协作式个人数据库模型会很有趣——在这种模型中，用户授权应用为他们协作的数据保持两个数据库同步——但这超出了我所构建、原型制作或能够完全理解的范围。 社交数据是另一种基于协作的数据类型。我们已经看到了大型组织存储我们的社交媒体数据、同时拥有控制这些数据如何展示给我们的算法和界面的弊端。像 ActivityPub（https://activitypub.rocks/）/ Mastodon 和 AT Protocol（https://atproto.com/）/ Bluesky 这样的项目，以不同方式（ActivityPub 的联邦 vs. AT Protocol 的存储与聚合分离）让用户对社会数据存放在何处有了更多选择。不过，有一个问题：这些项目提供了存储位置的选择，但存储的数据在与所有人的数据聚合成时间线之前是没有用的。时间线聚合的解决方案往往又回到中心化，因为很少有人愿意忍受跟踪数百万人在聚合状态下所说内容所需的基础设施和运营问题。鉴于创建一个可以访问和更新个人数据库的静态 HTML/CSS/JavaScript 应用是多么容易，我很想看到一个去中心化的极端方案：将社交网络好友的最新动态从他们各自的个人数据存储中聚合显示出来，而不依赖中心化的聚合器。 ## 我们该往何处去 最终，我希望更多人构建这样的软件：要求用户授权访问个人数据库，而不是要求用户与中心化数据库进行认证。我已经开始在自己的一些个人应用中这样做，从追踪我的 Todos（https://marcua.net/minitools/todos/）到追踪我的 Streaks（https://marcua.net/minitools/streaks/），甚至管理我博客上的订阅。由于 ayb 让我一键就能创建一个数据库，我构建了一些之前回避创建的应用——因为我既不想把敏感数据存放在别人的数据库里，也没有时间去管理自己的数据库。 为了在这一切基础上继续前进，以下几点是我接下来希望探索的方向： - 支持基本协作，例如记者或科学家等多位用户如何协作管理他们共同整理的数据集。 - 研究这一切如何与 local-first（https://www.inkandswitch.com/essay/local-first/）社区联系起来。你掌控着你的 ayb 数据库，但它仍然托管在远程，我很好奇本地 SQLite/DuckDB 数据库如何与远程数据库同步。 - 寻找方法，帮助其他应用开发者以让用户对其数据保有主动权的方式构建软件。 但最主要的是，我想看看我们能将多少登录界面替换为数据库授权界面。如果你想就这些主题中的任何一个进行合作，或者希望获得围绕个人数据库构建软件的帮助，欢迎联系我！ *感谢 Meredith Blumenstock 对这篇博客文章和视频提出的反馈。*