选择合适的 SSO 登录流程
不确定要启用哪种单点登录（SSO）登录流程？本指南将常见的企业场景与推荐的配置对应起来。
🌐 Not sure which single sign-on (SSO) sign-in flow to enable? This guide maps common enterprise scenarios to the recommended configuration.
从身份提供者 (IdP) 发起开始，这是默认的行为。它不需要域配置，并且适用于大多数企业使用场景。如果需要，你以后可以启用服务提供者 (SP) 发起。
🌐 Start with identity provider (IdP)-initiated, the default behavior. It requires no domain configuration, and works for most enterprise use cases. You can enable SP-initiated later if needed.
决策流程图 #
🌐 Decision flowchart
Do users need to start login at supabase.com?│├─ No → Use IdP-initiated only (default) ✅│ - No domain configuration needed│ - Simplest setup│ - Users access via IdP dashboard│└─ Yes → Do you need multiple SAML apps per domain? │ ├─ Yes → Use IdP-initiated only ✅ │ - Supports Dev/Staging/Prod under same domain │ - Each environment is a separate IdP tile │ └─ No → Enable both flows ✅ - SP-initiated for users who bookmark supabase.com - IdP-initiated still works from IdP dashboard - Configure email domains常见情况 #
🌐 Common scenarios
场景 1：多个环境（开发、测试、生产） #
🌐 Scenario 1: Multiple environments (dev, staging, prod)
你的情况：
- 你需要为开发、测试和生产创建不同的 Supabase 组织
- 所有员工都使用
company.com邮箱地址 - 你不能把不同的邮箱域分配给不同的环境
推荐配置： 仅 IdP 发起 ✅
为什么：
- 为每个环境在你的 IdP 中创建单独的 SAML 应用
- 所有应用都使用同一个域名（
company.com） - 用户点击“Supabase 开发”、“Supabase 预发布”或“Supabase 生产”块
- 没有域名冲突
如何配置：
- 在你的 IdP 中，创建三个 SAML 应用：
- "Supabase Dev" → 指向开发组织 ACS URL
- “Supabase 测试环境” → 指向测试组织 ACS 的 URL
- "Supabase 生产环境" → 指向 prod 组织的 ACS URL
- 在每个 Supabase 组织中：
- 启用单点登录
- 将“启用 SP 发起的登录”关闭
- 从对应的 IdP 应用配置元数据
- 用户通过 IdP 瓷贴访问每个环境
结果： 使用单个域实现环境的干净分离。
场景2：单一生产组织 #
🌐 Scenario 2: Single production organization
你的情况：
- 为你的整个公司提供一个 Supabase 组织
- 所有员工都使用公司邮箱域名
- 用户对 IdP 仪表盘感到满意
推荐配置： 仅 IdP 发起 ✅
为什么：
- 最简单的设置
- 无需域名配置
- 用户可以通过身份提供商一键访问 Supabase
- 潜在故障点更少
如何配置：
- 在你的 Supabase 组织中启用单点登录
- 将“启用 SP 发起的登录”关闭
- 配置身份提供者元数据
- 在你的身份提供商中创建 Supabase 应用图标
结果： 所有用户一键即可单点登录。
场景3：用户收藏了 supabase.com #
🌐 Scenario 3: Users bookmark supabase.com
你的情况：
- 用户经常直接收藏 supabase.com
- 你想支持从 Supabase 开始登录
- 单一字段，单一组织
推荐配置： 两个流程都启用 ✅
为什么：
- 支持从 supabase.com 开始的用户（SP 发起的）
- 也支持喜欢使用 IdP 图块（IdP 发起）的用户
- 灵活适应不同用户偏好
如何配置：
- 在你的 Supabase 组织中启用单点登录
- 将“启用 SP 发起的登录”打开
- 添加你的邮箱域名（例如：
company.com） - 配置身份提供者元数据
- 在你的 IdP 中创建 Supabase 应用图标（可选，但推荐）
结果： 用户可以从 Supabase 或 IdP 开始登录。
场景4：从密码认证迁移 #
🌐 Scenario 4: Migrating from password authentication
你的情况：
- 当前使用密码登录
- 切换到单点登录
- 用户习惯从 supabase.com 开始
推荐配置： 两个流程都启用 ✅
为什么：
- 现有用户常用的登录起点
- 逐步过渡到基于身份提供者的访问
- 用户适应后可以推广 IdP 瓷贴
如何配置：
- 确保至少存在一个非单点登录的所有者账户
- 启用单点登录，并将“启用服务提供方发起的登录”切换为 开启
- 添加邮箱域名
- 从自动加入关闭开始
- 小组测试
- 确认后自动加入
- 向用户传达新的身份提供商图标
- 逐渐鼓励由身份提供者发起的使用
迁移路径：
- 第1周： 启用两个流程，宣布单点登录可用
- 第2-4周： 监控使用情况，排查问题
- 第2个月起+: 推广 IdP 瓷片，如果使用量下降可以考虑禁用 SP 发起
场景5：拥有不同域名的多个子公司 #
🌐 Scenario 5: Multiple subsidiaries with different domains
你的情况：
- 母公司（
parent.com）及子公司（sub1.com、sub2.com） - 都使用同一个 Supabase 组织
- 每个域名都映射到同一个身份提供者
推荐配置： SP 发起，支持多个域 ✅
为什么：
- 在SP发起的配置中支持多个域
- 基于邮箱域名的自动路由
- 集中化的组织管理
如何配置：
- 在你的 Supabase 组织中启用单点登录
- 将“启用 SP 发起的登录”打开
- 添加所有域名：
parent.com、sub1.com、sub2.com - 配置身份提供者以接受所有域
- 在 IdP 中创建 Supabase 应用图块（IdP 发起的也可以用）
结果： 任何已配置域名的用户都可以访问组织。
场景6：带有客户专属单点登录的SaaS平台 #
🌐 Scenario 6: SaaS platform with customer-specific SSO
你的情况：
- 你正在开发一个SaaS产品
- 每个客户都有自己的组织
- 每个客户使用他们自己的身份提供者
推荐配置： 每个客户自行决定（通常由身份提供者发起）
为什么：
- 每个顾客可能有不同的偏好
- 为了简单起见，默认使用 IdP 发起
- 仅在客户要求时启用服务提供商发起
如何配置：
- 对于每个客户组织：
- 使用他们的 IdP 元数据启用单点登录
- 默认：保持服务提供商启动的 关闭
- 如果客户要求 SP 启动：切换 开启 并添加他们的域名
- 在客户入职时记录两种选项
- 让客户根据自己的工作流程选择
结果： 灵活的、针对客户的单点登录配置。
场景7：混合认证（SSO + 非SSO 用户） #
🌐 Scenario 7: Mixed authentication (SSO + non-SSO users)
你的情况：
- 一些用户通过单点登录认证（员工）
- 一些用户使用密码/社交认证（承包商、外部合作伙伴）
- 单一组织，成员混合
推荐配置： 两个流程都需要仔细规划 ⚠️
为什么：
- SSO 用户可以使用任意一种流程
- 非单点登录用户使用密码/社交登录
- 为每个群组设置不同的邀请类型
如何配置：
- 启用两种流程的单点登录（切换 SP 发起 开启）
- 配置员工邮箱域名
- 对员工使用需要 SSO 的邀请
- 给承包商使用非单点登录邀请
- 考虑关闭自动加入以控制成员资格
账号绑定注意
使用相同邮箱的 SSO 和非 SSO 账户会被视为不同的账户。如果一名员工有 alice@company.com，在以下情况下他们会有两个账户：
🌐 SSO and non-SSO accounts with the same email are treated as separate accounts. An employee with alice@company.com will have two accounts if they:
- 通过单点登录加入（SSO账号）
- 之前通过密码加入（非单点登录账户）
清楚地告诉每个用户应该使用哪种认证方法。
🌐 Communicate clearly which authentication method each user should use.
结果： 混合身份验证，明确分离。
配置快速参考 #
🌐 Configuration quick reference
| 使用场景 | IdP 发起 | SP 发起 | 所需域名 |
|---|---|---|---|
| 多环境（开发/测试/生产） | ✅ 仅限 | ❌ 不支持 | 否 |
| 单一生产组织 | ✅ 仅限 | ❌ 不支持 | 否 |
| 用户书签 supabase.com | ✅ 支持 | ✅ 支持 | 是 |
| 从密码迁移 | ✅ 支持 | ✅ 支持 | 是 |
| 多个邮箱域名 | ✅ 支持 | ✅ 支持 | 是（所有域名） |
| 客户专属 SSO（SaaS） | ✅ 默认 | 可选 | 每个客户 |
| 混合认证 | ✅ 支持 | ✅ 支持 | 是 |
测试你的配置 #
🌐 Testing your configuration
在选择你的登录流程后，仔细测试一下：
🌐 After choosing your sign-in flow, thoroughly test:
- IdP发起： 在IdP中点击应用图标 → 验证是否重定向到Supabase
- SP 发起: 访问 supabase.com/sign-in-sso → 输入邮箱 → 验证 IdP 重定向
- 自动加入： 使用新用户账号测试
- 域限制: 尝试不匹配的域（SP发起时应该失败）
查看我们全面的SSO 测试和最佳实践指南，了解详细的测试步骤。
🌐 See our comprehensive SSO Testing and Best Practices guide for detailed testing procedures.
什么时候更改配置 #
🌐 When to change configuration
你可以随时安全地更改登录流程配置：
🌐 You can safely change sign-in flow configuration at any time:
将 SP 发起添加到仅 IdP #
🌐 Adding SP-initiated to IdP-only
- 切换“启用 SP 发起的登录”为开启
- 添加所需域
- 与现有用户测试
- 对 IdP 发起的流程没有干扰
移除 SP 发起的 #
🌐 Removing SP-initiated
- 关闭“启用 SP 发起的登录”
- 域名已保留（以后可以重新启用）
- IdP 发起的仍然可以工作
- 那些收藏了 supabase.com 的用户现在需要使用 IdP 瓷贴了
无需迁移 - 更改会立即生效。
还不确定吗？ #
🌐 Still not sure?
如果你不确定该使用哪个配置：
🌐 If you're uncertain which configuration to use:
- 先从 IdP 发起的方式开始（最简单，适用于大多数情况）
- 在一小部分用户中进行测试
- 收集用户体验的反馈
- 如果用户请求，启用 SP 发起
- 监控使用情况，看看大家更喜欢哪个流程
可获得支持
如果你需要帮助为你的组织选择合适的配置，请联系 Supabase 支持，并提供你的使用案例的详细信息。我们很乐意提供个性化建议。
🌐 If you need help choosing the right configuration for your organization, contact Supabase support with details about your use case. We're happy to provide personalized recommendations.
下一步 #
🌐 Next steps
- 了解技术细节： 阅读 理解 SSO 登录流程
- **配置你的服务提供商：**请参考我们的特定服务提供商指南
- **测试你的设置：**查看 SSO 测试和最佳实践
- 启用自动加入： 配置 自动加入设置