Logto vs Supabase Auth：独立 IdP 与 Postgres 一体认证

Logto — 官网首页。

Supabase Auth — 产品页。

读者与要解决的问题

读者主要是 已在用或打算用 Supabase（Postgres、Edge Functions、自动 REST API）的团队，在问：身份层是 继续深度用 Supabase Auth，还是 单独上 Logto 这类独立 IdP。本文按官方文档可核对的事实，从架构、授权模型、扩展能力、计费与迁移风险做对比；不构成采购或合规建议，涉及合同、数据驻留与行业监管时请自行咨询法务与供应商。

一句话结论

数据与 API 已落在 Supabase、身份模型偏「用户—行级权限」且希望最少组件时，优先把 Supabase Auth 用透（JWT + RLS + Hooks）。 当你需要 跨多应用统一身份平面、复杂多租户组织与品牌化登录体验、并把身份运维从业务库 schema 中解耦 时，再认真评估 独立 IdP（如 Logto） 是否值得承担 双目录与同步 的复杂度。

双方定位（各是什么）

Supabase Auth 在官方文档中明确定位为：与 同一项目内的 Postgres 紧密集成的认证与鉴权组件；用户数据落在 专用 schema，通过 JWT 与 Row Level Security 把「谁已登录」与「能访问哪些行」绑在一起，并自然延伸到自动生成的 REST API 与客户端 SDK。它也支持作为相对独立的能力使用，但「与数据库一体」仍是其第一性原理。产品入口见 supabase.com/auth；技术细节见 Auth 文档。

Logto 在文档中描述为面向现代应用与 SaaS 的 IAM：提供控制台、终端用户登录体验、Management / Experience / Account 等 API、SDK 与 RBAC / 组织模板 等授权模型，部署上可选 Logto Cloud 或 自托管 OSS。其强项是 把「身份与访问」当作单独产品域 运营，而不是 Postgres 的一个子模块。入口见 Logto 文档首页。

架构与数据模型

Supabase Auth 的核心设计是：认证结果以 JWT 表达；授权大量依赖你在业务表上编写的 RLS 策略，并借助 auth.uid()、auth.jwt() 等辅助函数把请求映射到行级规则。文档强调：暴露 schema 上的表应启用 RLS，否则通过 publishable key 的 API 访问可能处于高风险状态。用户目录与 session 相关数据在 Auth 管理的 schema 中，业务表通过外键、触发器与其关联——这意味着 身份状态与业务库迁移、备份、恢复强耦合。以上表述均来自 RLS 与 Auth 官方说明。

Logto 则把身份服务作为 独立运行时（Cloud 或自建），应用通过 OIDC/OAuth 等协议对接；用户、组织、角色、应用注册等概念在 Logto 侧建模，再向你的业务系统发放令牌或同步事件。业务数据库 不必 把身份表与 auth.users 绑在同一实例语义里——代价是你需要 明确的应用侧映射（例如自己的 users 表与 Logto sub 对齐、处理 webhook、处理登出与令牌轮换）。

选型含义：若你的安全故事是「浏览器直连 Postgres + RLS 纵深防御」，Supabase 路径更顺；若你的故事是「多产品共用一个 IdP、统一控制台与组织治理」，Logto 路径更顺。

认证、授权与企业能力

认证方式：Supabase 文档列出密码、Magic link、OTP、社交登录、自定义 OAuth/OIDC IdP 以及面向企业的 SSO / SAML 2.0 等能力；具体可用性与计划限制以控制台与文档为准。

授权模型：Supabase 侧「能做什么」大量体现在 RLS 策略 与 JWT claims 的组合上，文档也提醒：user_metadata 可被终端用户改写，不宜把敏感授权塞进可被用户改的 claim；更适合放 raw_app_meta_data 等路径（见 RLS 文档对 auth.jwt() 的说明）。Logto 侧则强调 全局 RBAC 与面向 SaaS 的 Organization template：组织角色、组织权限、与 API 资源的映射在模板层统一演进——适合「每个客户组织一套一致角色」的 B2B 叙事。

流程扩展：Supabase 提供 Auth Hooks（Postgres 函数或 HTTP，含 Standard Webhooks 安全头、超时与重试语义），可在建用户、签发 token、发信发短信等节点插入逻辑。Logto 则通过 Management API、Experience、连接器生态 等组合扩展登录与供应侧能力；二者扩展哲学不同：前者贴近 数据库与 Edge，后者贴近 身份产品与控制台。

开发者体验与集成范式

在 Supabase 生态内，常见路径是：前端或 Edge 使用官方客户端拿到 session，同一套 SDK 访问数据库与 Storage；权限思考方式是「先写 RLS，再写查询」。优点是样板少、全栈心智统一；缺点是团队必须 持续投入 SQL 策略治理，复杂跨表、跨服务授权容易堆在数据库层。

对接 Logto 的常见路径是：应用作为 OIDC 依赖方 接入，业务服务验证 access token 或调用 Logto API；权限与组织模型 在 IdP 与业务层之间切分。优点是身份边界清晰、便于多语言后端共用；缺点是多一跳服务、对团队 协议与令牌生命周期 的要求更高。

运维、部署与边界

Supabase Auth 随托管 Supabase 项目运维；升级、备份、区域与高可用由平台承担（具体以组织计划与合同为准）。Logto 可选 Cloud 或 OSS 自托管：自托管带来数据主权与定制空间，也意味着补丁、扩容、密钥与数据库备份需自行负责。

尤其注意：Logto 官方列出 部分能力当前仅 Cloud 提供（例如控制台多租户协作、内置邮件服务、IdP-initiated SSO、SAML 应用数量在 OSS 的限制等），详见 OSS 功能说明与限制表。若你被「开源」吸引，务必逐条对照 自己命中的限制。

计费与规模（可核对口径）

Supabase 对 Auth 相关用量采用 MAU、第三方 IdP MAU、SSO MAU 等维度计费，并在文档中给出 各计划配额与超出后按 MAU 计费 的表格（例如 Free 档 MAU 配额、Pro/Team 档与超出用量等），详见 Monthly Active Users 用量说明 及同系列的 Third-Party、SSO、MFA 文档。具体金额与发票行项以你的组织账单与官网定价为准，此处不抄数字以免过期。

Logto 公开站宣称 Cloud 免费档 MAU 与 token 计费 等策略（以 logto.io 与文档实时页面为准）。OSS 无软件许可费，但基础设施与人力成本需自建模型评估。

从 总拥有成本 看：Supabase 侧容易低估的是 RLS 治理、Hook 运维与策略回归测试 的人力；Logto 侧容易低估的是 自托管集群、升级与多环境同步。两者都可能随规模上升而显著增加成本，只是记账科目不同。

安全与合规责任

无论选哪条路径：服务密钥（如 Supabase service_role、Logto client secret）都不能进浏览器；RLS 与策略错误会导致数据越权；Hook 与 Edge 逻辑写错会造成认证链路不可用。托管产品的 区域、DPA、行业合规 以供应商文件为准，本文不做背书。

Logto 不适合 / Supabase Auth 不适合（各举三例）

Logto 未必合适：你几乎不做多应用身份复用、团队极小且只想要 最少 moving parts；你强依赖 「JWT + RLS 一体化」 且不愿维护 OIDC 会话语义；你无法接受 OSS 功能限制 又暂不愿上 Cloud。

Supabase Auth 未必合适：你要 跨多个独立产品 共用一套组织与 SSO 控制台，而不仅是「一个数据库项目」；你希望 把身份治理从 DBA 职责中剥离；你需要 深度品牌化与多租户成员治理 且不想把规则全部写进 SQL。

迁移与双栈风险

从 Supabase Auth 迁出或并行双栈时，重点清单包括：用户主键映射（auth.users 与自有用户表）、触发器与级联、RLS 中对 auth.uid() 的依赖、refresh 会话与 Webhook 顺序、以及对外 OAuth 回调域名的切换窗口。反向从 Logto 回到「纯 Supabase」也需评估 组织模型与 token claims 是否能在 RLS 中无损表达。建议任何迁移都按 环境分段演练，并在低峰期切换。

选型决策指引

你的现状	更倾向
单项目、强 Postgres、团队熟悉 SQL，身份=用户+行权限	先把 Supabase Auth + RLS 做扎实
多应用、统一登录与组织治理、身份运维想产品化	评估 Logto（或同类 IdP） 作为独立平面
需要大量 Hook 定制发信/发码、且逻辑贴近数据库	Auth Hooks + Postgres/Edge 往往更顺手
需要组织模板、跨租户 RBAC、控制台运营身份	看 Logto Organization / RBAC 文档 是否命中
必须自托管且命中 Logto OSS 限制表中的条目	计划 Cloud 或改需求，而不是假设 OSS=Cloud

下一步

• Supabase：Auth 产品、Auth 文档、RLS、Auth Hooks、MAU 计费说明
• Logto：文档首页、Quick starts、OSS 与限制、Organization template