身份认证体系概览：认证与授权的区别

身份认证体系概览：认证与授权的区别

在深入具体登录方式之前，必须先澄清一个被频繁混淆的概念——认证（Authentication）与授权（Authorization）。这一字之差，决定了你对整个安全体系的理解是否正确。

认证 vs 授权：你是谁 vs 你能做什么

• 认证（Authentication，常缩写为 AuthN）：回答「你是谁」，即验证用户的身份。典型动作是登录——你声称自己是某个邮箱的主人，系统通过密码或第三方验证这个声称是否成立。
• 授权（Authorization，常缩写为 AuthZ）：回答「你能做什么」，即决定一个已认证的用户拥有哪些权限。典型问题是「这个用户能看这笔订单吗？」「他能删除这篇文章吗？」

一个简单的类比：认证是出示身份证证明你是张三，授权是门禁系统判断张三能不能进这间机房。两者前后衔接——先认证，后授权。

Supabase 中两者各自由谁负责

在 Supabase 体系里，这两个职责由不同部分承担：

• 认证由 Auth 服务负责：它处理登录凭证的校验、签发令牌、管理会话与用户表。第 4 章的主题就是认证。
• 授权主要由 RLS 负责：行级安全策略基于已认证用户的身份，在数据库行级别决定读写权限。这是第 5 章的主题。

理清这一点很重要：Supabase 的 Auth 解决「是谁」，RLS 解决「能做什么」。它们协作完成完整的安全链路，但职责分明。常见误区是想用 Auth 直接控制「能不能看某行数据」——这不是 Auth 的职责，而应交给 RLS。

用户表：认证数据的归宿

Supabase Auth 的一大特色是用户数据存储在数据库的专用模式中（一张通常名为 auth.users 的表）。这意味着：

• 用户本身就是数据库中的行，可以用 SQL 查询、管理。
• 业务表可通过外键直接关联用户 id（UUID），天然建立「某数据属于某用户」的关系。
• 第 5 章的 RLS 能直接引用当前登录用户的 id 来做行级判断。

这种「认证即数据」的设计，是 Supabase 区别于把用户体系封闭在外的 BaaS 的关键，也是它安全模型强大的根源。

认证的要素：标识、凭证与令牌

任何认证流程都包含三个要素：

1. 标识（Identifier）：用什么唯一代表一个用户，如邮箱、手机号、用户名。
2. 凭证（Credential）：用来证明「我确实是这个标识的主人」，如密码、OAuth 授权、验证码。
3. 令牌（Token）：认证成功后系统签发的「通行证」，后续请求携带它即可证明已登录，无需反复提交凭证。

不同登录方式的差异，本质上是这三要素的不同组合。下一节将逐一展开各类登录方式。

多端认证的统一性

现代应用通常要同时支持 Web、移动端、小程序等多种客户端。Supabase Auth 的设计是端无关的：无论哪种客户端，都用同一套用户体系、同一套令牌机制。一个用户在 Web 注册后，可用同样的邮箱密码在 App 登录；不同端的会话相互独立但共享同一身份。

这种统一性简化了多端开发——你不需要为每种端各搭一套用户系统，所有端共用 Supabase Auth。

安全要点先行

在进入具体登录方式前，先确立几条贯穿全章的安全原则：

• 凭证不应明文存储：密码等敏感凭证由 Auth 服务加密处理，应用代码不应接触原始密码。
• 令牌需妥善保管：令牌等同于登录态，泄露即等同于账号泄露。
• 最小权限：默认只授予用户完成其操作所需的最低权限，多余的一律不给。
• 纵深防御：认证之外，还要用 RLS、网络限制、密钥保护等多重手段共同守护安全。

小结

认证回答「你是谁」，授权回答「你能做什么」；在 Supabase 中，前者由 Auth 负责，后者主要由 RLS 负责，而用户数据本身存储在数据库中，让两者无缝衔接。建立这个概念框架后，下一节我们将逐一认识各类登录方式，看看「认证」具体是如何落地的。