Skip to content
Platform

SSO 测试与最佳实践

在配置好你的单点登录（SSO）提供商后，正式在组织内部署之前，彻底测试是非常必要的。本指南介绍了测试流程、常见问题的排查方法，以及保持安全 SSO 设置的最佳实践。

🌐 After configuring your SSO provider, thorough testing is essential before rolling out to your organization. This guide covers testing procedures, troubleshooting common issues, and best practices for maintaining a secure SSO setup.

预配置检查清单 #

🌐 Pre-configuration checklist

在你开始测试之前，先确认一下：

🌐 Before you begin testing, verify:

  • 组织有团队或企业计划
  • 已决定登录流程类型（由身份提供者发起、由服务提供者发起，或两者都有）- 查看 选择登录流程
  • 已识别的电子邮件域（仅在使用 SP 发起时需要）
  • 自动加入设置和默认角色已确定
  • 至少存在一个非SSO所有者账户（关键安全要求）
  • 证书到期日期已记录（尤其是 Google Workspace 的）

测试登录流程 #

🌐 Testing sign-in flows

在测试自动加入和其他功能之前，先确认哪些登录流程适用于你的 SSO 配置。有关技术细节，请参阅 了解 SSO 登录流程。

🌐 Before testing auto-join and other features, verify which sign-in flows work for your SSO configuration. See Understanding SSO Sign-in Flows for technical details.

测试 IdP 发起的登录 #

🌐 Testing IdP-initiated sign-in

IdP发起的登录始终可用，并且不需要域配置。这应该是你的主要测试。

🌐 IdP-initiated sign-in is always available and doesn't require domain configuration. This should be your primary test.

测试流程：

  1. 来自身份提供者的访问：
    • 打开你的 IdP 控制面板（Okta、Azure AD、Google Workspace）
    • 找到你的 Supabase 应用图标或书签
    • 点击应用图标
  2. 验证身份：
    • 如果已经通过 IdP 验证：立即重定向到 Supabase
    • 如果未认证：完成 IdP 登录流程，然后重定向
    • 检查你是否登录到正确的组织
    • 核实用户资料信息是否填写正确
  3. 确认成功：
    • 没有出现错误信息
    • 组织仪表板加载正常
    • 用户属性（名称、邮箱）映射正确

预期结果：

  • ✅ 从身份提供商直接登录，无需中间步骤
  • ✅ 无论域名配置如何都能工作
  • ✅ 用户信息已正确从身份提供者映射

测试 SP 发起的登录 #

🌐 Testing SP-initiated sign-in

SP 发起的登录需要域配置。只有在你启用了 SP 发起流程时才测试这个。

🌐 SP-initiated sign-in requires domain configuration. Only test this if you've enabled SP-initiated flow.

前提条件：

  • “启用 SP 发起的登录”开关已开启
  • 至少配置了一个邮箱域

测试流程：

  1. 从 Supabase 开始：
  2. 输入邮箱：
    • 使用与配置域名匹配的邮箱
    • 点击“继续”
  3. 验证重定向链：
    • 应该重定向到你的身份提供者
    • 如有需要，请完成认证
    • 应该重定向回 Supabase
    • 检查你是否在正确的组织
  4. 测试域名匹配：
    • 试试邮箱域名不匹配
    • 应该会收到错误：“未找到 SSO 提供商”
    • 确认基于域名的路由有效

预期结果：

  • ✅ 匹配域的用户已被重定向到身份提供者
  • ✅ 不匹配的域名会显示清晰的错误信息
  • ✅ 验证成功后会重定向回 Supabase

仅限 IdP 发起的测试（不涉及域） #

🌐 Testing without domains (IdP-initiated only)

这是对无域提供商的关键测试，它们允许每个域拥有多个 SAML 应用。

🌐 This is a critical test for domainless providers, which enable multiple SAML apps per domain.

测试场景：

你已经配置了单点登录 (SSO)：

🌐 You've configured SSO with:

  • “启用 SP 发起的登录” 关闭（或未配置任何域）
  • 已配置身份提供者元数据
  • 属性映射已配置

测试流程：

  1. 验证 SP 发起不可用：
    • 访问 使用 SSO 登录
    • 输入你的邮箱地址
    • 预期：错误信息“未找到 SSO 提供商”
    • 这是正常行为（没有域名 = 没有 SP 发起）
  2. 验证 IdP 发起的是否有效：
    • 打开 IdP 仪表板
    • 点击 Supabase 应用图标
    • 应该可以成功登录
    • 验证正确的组织访问权限
  3. 确认多环境模式是否有效（如适用）：
    • 如果你有多个环境（开发/测试/生产）
    • 每个应用在身份提供者里都应该有独立的应用图标
    • 单独点击每个瓷砖
    • 核实每条路线是否到正确的组织

预期结果：

  • ✅ IdP发起的登录工作得非常顺利
  • ❌ 服务提供商发起的登录不可用（预期如此）
  • ✅ 通过不同的格子可以访问多个环境
  • ✅ 环境之间没有域名冲突

登录流程核对清单 #

🌐 Sign-in flow verification checklist

  • IdP 发起的登录可以从 IdP 仪表板进行
  • SP 发起的登录有效（如果域已配置）
  • 如果没有配置域名，SP 发起会被正确阻止
  • 域名匹配对 SP 发起的情况工作正常
  • 不匹配的域显示相应的错误
  • 多个环境可以正确路由（如果使用多个提供商的话）
  • 如果两个都启用，两个流程会同时工作

测试 SSO 登录流程 #

🌐 Testing SSO sign-in flow

基本登录测试 #

🌐 Basic sign-in test

  1. 导航到 SSO 登录页面：
    • 访问 使用 SSO 登录
    • 或者从 Supabase 主登录页面点击“使用 SSO 登录”
  2. 输入你的邮箱地址：
    • 使用一个在你的单点登录设置中配置过域名的邮箱
    • 点击“继续”
  3. 验证重定向到身份提供者：
    • 你应该会被重定向到你的身份提供者（Okta、Azure AD、Google Workspace）
    • 如果你已经登录了你的身份提供者，你可能会被自动重定向回来
    • 如果未登录，请完成 IdP 登录流程
  4. 确认登录成功：
    • 你应该会被重定向回 Supabase 仪表板
    • 你的个人资料应该显示你的单点登录身份
    • 检查一下你的用户信息是否填写正确

多用户测试 #

🌐 Multi-user testing

用另外2-3个用户测试一下以确认：

🌐 Test with 2-3 additional users to verify:

  • 拥有匹配邮箱域的用户可以通过单点登录登录
  • 用户属性（名称、邮箱）映射正确
  • 用户会获得对组织的适当访问权限（如果使用自动加入的话）
  • 没有匹配域的用户无法使用这个组织的单点登录

测试自动加入 #

🌐 Testing auto-join

🌐 Recommended testing workflow

  1. 从禁用自动加入开始:

    • 前往 SSO 设置
    • 确保“注册时加入组织”是关闭的
    • 配置你的单点登录提供商
    • 测试基本的 SSO 登录（见上文）

  2. 测试成功后启用自动加入：

    • 返回 SSO 设置
    • 把“注册时加入组织”切换为启用
    • 选择默认角色（推荐：开发者）
    • 点击“保存更改”

  3. 使用你的账户测试自动加入：

    • 完全退出 Supabase
    • 通过 SSO 再次登录
    • 确认你是否已被自动加入该组织
    • 检查你是否收到了正确的默认角色

  4. 与更多用户测试：

    • 让拥有相同邮箱域名的同事通过SSO登录
    • 他们应该自动加入这个组织
    • 确认他们收到了正确的默认角色
    • 在 /dashboard/org/_/team 查看组织成员列表

  5. 测试域限制（如果使用 SP 发起）：

    • 试着用未配置域名的邮箱登录
    • 用户应该可以登录，但不会看到组织
    • 这确认了基于域的访问控制正在工作
    • 注意：仅在 IdP 发起的情况下，域匹配不适用

  6. 测试幂等性（防止重复加入成员）：

    • 使用已经是会员的账户重新登录
    • 确认没有错误发生
    • 检查成员列表 - 不应该有重复条目
    • 确认角色没有意外变化
    • 预期：自动加入能优雅地处理已有成员

  7. 使用无域（仅 IdP 发起）配置进行测试：

  • 如果你在没有域名的情况下配置了单点登录（仅 IdP 发起）:
    • 启用自动加入
    • 新用户通过 IdP 应用图标访问
    • 验证自动加入在不检查域的情况下是否工作
    • 用户已自动加入组织
    • 角色已正确分配
    • 预计：自动加入对 IdP 发起的操作无论邮箱域名都有效
  1. 测试自动加入重新启用：
    • 关闭自动加入
    • 让新用户通过 SSO 登录
    • 确认他们没有被加入到组织
    • 重新启用自动加入
    • 同一个用户退出后又登录了
    • 确认他们现在已经加入组织
    • 预期：启用此功能时，现有的 SSO 用户会自动加入

自动加入验证清单 #

🌐 Auto-join verification checklist

  • 启用后会自动加入
  • 用户获得正确的默认角色
  • 不匹配的域名会被排除（如果使用带域名的 SP 发起的话）
  • 现有用户在下次登录时会自动加入（不仅限于新注册用户）
  • 自动加入可以根据需要禁用或重新启用
  • 自动加入是幂等的（不会有重复成员）
  • 自动加入仅适用于 IdP 发起（不适用域）
  • 自动加入适用于 IdP 和 SP 发起的流程

测试邀请 #

🌐 Testing invitations

制作和测试邀请函 #

🌐 Creating and testing invitations

  1. 创建需要 SSO 的邀请：
    • 导航到 组织团队设置
    • 点击“邀请”来创建新的邀请
    • 选择 “需要 SSO” 选项
    • 输入收件人邮箱并选择角色
    • 发送邀请
    • 收件人必须通过单点登录（SSO）签署以接受
  2. 创建非SSO邀请：
    • 创建一个新邀请
    • 选择 “非单点登录” 选项
    • 发送邀请
    • 收件人可以用密码或社交账号登录来接受
  3. 测试 SSO 不匹配场景：
    • 创建一个需要单点登录的邀请
    • 让收件人在使用非SSO账户登录时尝试接受
    • 错误应该显示：“邀请令牌的单点登录提供商与你登录的不同”
    • 收件人应该退出并通过单点登录重新登录
    • 就能成功接受邀请

常见的邀请场景 #

🌐 Common invitation scenarios

  • 全SSO组织：邀请时始终选择“需要SSO”
  • 混合组织：根据收件人的认证方式选择
  • 过渡到单点登录（SSO）：先从非SSO用户开始，逐步添加SSO用户，在移除旧的认证方法之前保持非SSO所有者

邀请验证清单 #

🌐 Invitation verification checklist

  • 需要 SSO 的邀请可以正常使用
  • 非单点登录邀请可以正常使用
  • SSO不匹配错误信息清晰
  • 混合认证组织运作正常
  • 如果需要，邀请可以重新发送

测试 SSO 账户限制 #

🌐 Testing SSO account restrictions

SSO 账户有特定限制，以防止意外导致组织无法访问。

🌐 SSO accounts have specific restrictions to prevent accidental organization lockouts.

测试 SSO 账户删除限制 #

🌐 Testing SSO account deletion restrictions

  1. 使用 SSO 账户登录：
    • 通过 SSO 验证（IdP 或 SP 发起）
    • 前往 SSO 设置
    • 确认你是组织所有者
  2. 尝试删除单点登录提供商：
    • 试着删除单点登录提供商
    • 预期： 显示防止删除的错误信息
    • 错误：只有非SSO账户才能删除SSO提供者
    • 删除应该被阻止
  3. 验证其他 SSO 操作是否正常：
    • SSO 账户可以读取 SSO 配置
    • SSO 账户可以更新 SSO 设置
    • SSO账户可以禁用（但不能删除）SSO提供商
    • 只有删除受到限制

预期结果：

  • ❌ SSO 账户无法删除 SSO 提供商
  • ✅ 清晰的错误信息解释了限制
  • ✅ 其他 SSO 管理操作仍然可用

使用非单点登录所有者账户进行测试 #

🌐 Testing with non-SSO owner account

  1. 使用非单点登录账户登录：
    • 使用密码或社交账号
    • 必须是组织所有者
    • 前往 SSO 设置
  2. 验证删除功能：
    • 非SSO所有者可以删除SSO提供商
    • 删除需额外安全检查（见下一节）
    • 系统允许进入删除流程

预期结果：

  • ✅ 非SSO用户可以使用删除功能
  • ✅ 仍需进行安全检查（非SSO账户要求）

SSO账户限制清单 #

🌐 SSO account restrictions checklist

  • SSO 账户无法删除 SSO 提供商
  • SSO 账户可以更新 SSO 设置
  • SSO 账户可以禁用 SSO 提供商
  • 非SSO所有者可以删除SSO提供商
  • 错误信息清楚地说明了限制
  • 限制适用于所有单点登录账户（不仅仅是某些角色）

常见问题与解决方法 #

🌐 Common issues and troubleshooting

基于以前需要支持干预的客户痛点：

🌐 Based on customer pain points that previously required support intervention:

关键问题 #

🌐 Critical issues

已启用自动加入，但用户没有自动加入 #

🌐 "Enabled auto-join but users aren't automatically joining"

导致这个的常见工作流程：

  1. 组织所有者在禁用自动加入的情况下测试单点登录
  2. 测试后自动加入
  3. 再次登录时期待自动加入，但什么也没发生

解决方案：

  • 自动加入现在会在每次登录时生效，而不仅仅是第一次注册
  • 测试：启用自动加入，完全退出，然后通过单点登录重新登录
  • 如果还是不行，确认域名配置和用户邮箱完全一致

无法邀请使用正确认证类型的用户 #

🌐 "Can't invite users with the right authentication type"

之前的限制：

  • 邀请类型是从邀请人的账户类型继承的
  • 非SSO所有者不能发送SSO邀请
  • SSO 所有者不能发送非 SSO 邀请

解决方案：

  • 在创建邀请时，明确选择“需要 SSO”或“非 SSO”
  • 混合组织现在完全支持了
  • 同一个组织里可以同时存在SSO用户和非SSO用户

接受邀请时显示“SSO 提供商不匹配”错误 #

🌐 "Invitation acceptance shows 'SSO provider mismatch' error"

原因: 用户使用错误的身份验证方法登录以接受邀请

解决方案：

  1. 检查邀请是否需要使用 SSO 或非 SSO 登录
  2. 完全退出
  3. 用正确的方式登录（单点登录或密码/社交账户）
  4. 接受邀请
  5. 如果不确定类型，可以联系发送邀请的人

删除了 SSO 提供商，现在成员无法登录 #

🌐 "Deleted the SSO provider and now members can't sign in"

最近的安全改进：

  • 系统现在会在删除之前自动移除所有 SSO 成员
  • 在允许删除之前，至少必须有一个非SSO的拥有者

最佳做法：

  • 在删除 SSO 提供商之前添加一个非 SSO 所有者账户
  • 在删除之前通知受影响的用户
  • 如果只是暂时变化，考虑禁用而不是删除

测试安全提供者删除 #

🌐 Testing safe provider deletion

了解删除行为 #

🌐 Understanding deletion behavior

当一个单点登录提供商被删除时：

🌐 When an SSO provider is deleted:

  1. 系统会验证至少存在一个非单点登录的拥有者账户
  2. 所有 SSO 成员会被自动 从组织中移除
  3. SSO 提供商配置已被删除
  4. 组织继续由剩余的非SSO成员运营

这种行为可以防止无法再进行身份验证的“孤立”SSO账户。

🌐 This behavior prevents "orphaned" SSO accounts that can no longer authenticate.

测试 1：在没有非SSO账户的情况下删除（应该失败） #

🌐 Test 1: Deletion without non-SSO accounts (should fail)

设置：

  • 只有单点登录账户的组织
  • 所有所有者通过单点登录认证
  • 没有密码或社交认证的所有者

测试流程：

  1. 核实当前状态：
    • 查看团队设置
    • 确认所有所有者都是 SSO 账户
    • 没有非SSO所有者存在
  2. 尝试删除：
    • 前往 SSO 设置
    • 尝试删除 SSO 提供商
    • 预期： 错误，防止删除
    • 错误消息："至少需要一个非单点登录账户以保持组织访问权限"
  3. 验证组织状态：
    • SSO 提供商仍然存在
    • 所有 SSO 成员仍然可以访问
    • 没有发生部分删除

**预期结果：**❌ 删除被阻止，并显示明确的错误信息

测试2：添加非SSO拥有者并重试删除（应该成功） #

🌐 Test 2: Add non-SSO owner and retry deletion (should succeed)

设置：

  1. 添加非SSO所有者：
    • 创建或邀请非单点登录用户（密码或社交登录）
    • 提升为所有者角色
    • 重要: 删除前确认非SSO所有者可以登录
    • 安全存储凭证
  2. 记录 SSO 成员：
    • 注意当前 SSO 成员数量
    • 记录SSO成员的邮箱地址（用于验证）

测试流程：

  1. 尝试以非SSO所有者身份删除：
    • 使用非单点登录的账户登录
    • 前往 SSO 设置
    • 删除 SSO 提供商
    • 确认删除
  2. 验证删除结果：
    • 所有 SSO 成员已被移出组织
    • 查看团队设置
    • 只有非SSO成员应该留下
    • SSO 配置已被完全移除
  3. 验证非SSO访问：
    • 非SSO拥有者保留完全访问权限
    • 组织仍然运作正常
    • 可以邀请新成员（非SSO邀请）

预期结果： ✅ 删除成功，SSO 成员已移除，非 SSO 访问保留

测试3：删除时移除成员 #

🌐 Test 3: Member removal during deletion

在隔离环境中使用测试账号进行测试。

设置：

  1. 创建测试组织
  2. 启用单点登录
  3. 添加多个 SSO 成员（3-5 个测试用户）
  4. 至少添加一个非SSO所有者
  5. 在删除前记录成员列表

测试流程：

  1. 删除前跟踪成员：
    • 注意 SSO 成员数量（例如，5 个 SSO 成员）
    • 记下 SSO 成员的邮箱地址
    • 记录他们的角色
  2. 删除 SSO 提供商：
    • 以非单点登录所有者身份登录
    • 删除 SSO 提供商
    • 系统可能显示成员数正在减少
  3. 验证成员移除：
    • 查看组织成员名单
    • 所有 SSO 成员都应该走了
    • 只剩下非单点登录成员了
    • 之前的单点登录用户无法访问组织

预期结果： 所有SSO成员已被干净移除，没有孤立账户

测试 4：混合身份验证场景 #

🌐 Test 4: Mixed authentication scenario

设置：

  • 有 SSO 和非 SSO 成员的组织
  • SSO 成员：员工（通过 SSO）
  • 非单点登录成员：承包商（密码认证）
  • 混合所有者类型

测试流程：

  1. 确保存在非单点登录的所有者：
    • 至少验证一个非SSO所有者
    • 在删除前测试他们的登录
  2. 删除 SSO 提供商：
    • 系统允许删除（存在非SSO所有者）
    • 确认删除
  3. 验证选择性移除：
    • SSO 成员被移除（员工）
    • 非单点登录成员保留（合同工）
    • 组织仍然运作
    • 非SSO拥有者可以管理组织

预期结果： ✅ 有选择地删除 - 仅影响 SSO 成员

安全删除确认清单 #

🌐 Safe deletion verification checklist

  • 没有非单点登录的账户无法删除
  • 错误信息清楚地说明了要求
  • 添加非单点登录所有者可以删除
  • 删除时会移除所有 SSO 成员
  • 非SSO成员不受SSO提供商删除影响
  • 组织仍然可以通过非单点登录账户访问
  • 删除后，单点登录配置已完全移除
  • 在删除前测试的非SSO所有者账户

安全删除的最佳做法 #

🌐 Best practices for safe deletion

在删除 SSO 提供者之前：

  1. 创建专用非SSO所有者账户
    • 使用密码认证
    • 测试这个账户是否可以登录
    • 把凭证存到安全的密码管理器里
    • 验证所有者权限
  2. 沟通计划：
    • 在删除前通知所有 SSO 成员
    • 解释一下他们会失去组织访问权限
    • 提供删除时间表
    • 如有需要，可提供其他访问方式（重新邀请非单点登录）
  3. 文档:
    • 将被移除的成员文档
    • 如果需要，计划重新添加用户
    • 有回滚方案（如有需要，重新配置单点登录）

删除后：

  1. 验证组织功能：
    • 测试非SSO拥有者访问
    • 确认关键功能是否正常
    • 检查已移除的 SSO 成员
  2. 用户交流：
    • 确认用户删除已完成
    • 提供备用访问方法的说明
    • 回答有关恢复访问权限的问题

配置问题 #

🌐 Configuration issues

单点登录根本用不了 #

🌐 "SSO sign-in doesn't work at all"

常见原因：

🌐 Common causes:

  • 元数据 URL/文件不正确或已过期
  • 证书已过期（尤其是 Google Workspace - 设置时检查）
  • 属性映射配置错误
  • 用户未在身份提供者中分配到 Supabase 应用
  • 邮箱域名未在 Supabase SSO 设置中配置
  • 用户邮箱域名与配置的域名不匹配

故障排除步骤：

  1. 确认元数据 URL/文件可访问且是最新的
  2. 查看证书到期日期
  3. 验证属性映射（必须映射电子邮件）
  4. 确认用户已在身份提供商中分配到应用
  5. 检查 Supabase 中的域配置是否与用户邮箱匹配
  6. 查看 IdP 日志中的身份验证错误

属性映射错误或用户数据缺失 #

🌐 "Attribute mapping errors or missing user data"

要求：

  • 邮件映射到 email 是必须的
  • 属性键必须和提供者中显示的一模一样
  • 使用供应商预设（Okta、Azure、G Suite）以避免错误

故障排除：

  1. 确认邮箱属性映射正确
  2. 检查属性名称是否与你的 IdP 配置完全匹配
  3. 测试映射是否返回预期的用户数据
  4. 使用 IdP 测试工具看看发送了哪些属性

无法删除 SSO 提供商 #

🌐 "Cannot delete SSO provider"

错误: “至少需要一个非SSO账户”

解决方案：

  1. 创建或将现有成员转换为非SSO的所有者账户
  2. 确认非SSO所有者可以登录
  3. 然后继续删除单点登录提供商

为什么需要这个： 如果 SSO 无法使用，可以防止整个组织被锁定

最佳实践 #

🌐 Best practices

安全与保障 #

🌐 Security and safety

关键：至少保留一个非SSO的拥有者账户 #

🌐 CRITICAL: Maintain at least one non-SSO owner account

  • 必需 防止整个组织被完全锁定
  • 在删除 SSO 提供商时，系统会强制执行这一点
  • 在启用单点登录之前，先创建专用的非单点登录所有者
  • 把凭证安全地存到密码管理器里
  • 在进行关键更改前确认这个账户能登录

监控证书过期 #

🌐 Monitor certificate expiration

  • 在证书到期前30天设置日历提醒
  • 特别重要，适用于 Google Workspace（在设置过程中会显示证书）
  • 在证书更新后测试 SSO
  • 在 IdP 证书更新后在 Supabase 更新元数据
  • 把计划更新告诉团队

仔细配置域名 #

🌐 Configure domains carefully

  • 只使用特定的公司邮箱域名
  • 公共域名（gmail.com、yahoo.com 等）会被自动屏蔽
  • 对你不完全控制的域名要小心
  • 支持承包商/收购的多个字段
  • 记录哪些域名已配置以及原因

定期访问审查 #

🌐 Regular access reviews

  • 定期查看组织成员列表
  • 确认自动加入的角色仍然合适
  • 检查孤立或不活跃的账户
  • 与IT团队协调用户访问审查
  • 移除不再需要访问权限的成员

配置和测试 #

🌐 Configuration and testing

🌐 Recommended SSO setup workflow

  1. 创建或确认非单点登录的账户是否存在
  2. 配置 SSO 提供商，自动加入 已禁用
  3. 使用你自己的账户测试 SSO 登录
  4. 检查属性映射是否正确
  5. 与另外2-3个用户测试
  6. 如果想的话，启用自动加入
  7. 彻底测试自动加入功能
  8. 把 SSO 可用性通知给团队

自动加入的角色选择 #

🌐 Role selection for auto-join

  • 默认使用 "开发者" 角色（最小权限原则）
  • 避免使用“所有者”或“管理员”进行自动加入
  • 根据需要单独提升用户
  • 查看并记录你的访问控制策略
  • 查看访问控制文档了解角色详情

属性映射 #

🌐 Attribute mapping

  • 电子邮件映射是必须的
  • 有可用时使用提供商预设（Okta、Azure、G Suite）
  • 记录自定义映射以备将来参考
  • 测试映射返回预期的用户数据
  • 在各个环境中保持映射一致

多环境策略 #

🌐 Multi-environment strategy

  • 考虑为开发/测试/生产使用不同的提供商
  • 先在非生产环境测试配置更改
  • 保持提供者配置同步
  • 记录不同环境的差异
  • 详情请参见 多重 SSO 提供商指南

运行与维护 #

🌐 Operations and maintenance

在进行 SSO 更改之前 #

🌐 Before making SSO changes

  • 提前通知团队成员
  • 如果可能的话，安排在使用低峰期
  • 准备好回滚计划
  • 把 Supabase 支持联系信息随手放好
  • 记录你在改什么以及原因

在进行 SSO 配置更改后 #

🌐 After SSO configuration changes

  • 立即测试登录
  • 确认自动加入功能仍然有效（如果已启用）
  • 检查邀请是否有效
  • 确认没有用户被锁定
  • 监控团队的支持请求

在删除 SSO 提供商之前 #

🌐 Before deleting SSO provider

  • 确认至少存在一个非单点登录拥有者（系统会强制执行）
  • 请理解，所有 SSO 成员将会被自动移除
  • 在删除之前先和受影响的用户沟通
  • 如果是临时的，考虑禁用而不是删除
  • 有计划让用户在需要时重新获得访问权限

与IT/安全团队协调 #

🌐 Coordinating with IT/Security team

  • SSO 的变更可能会影响合规要求
  • 证书续期需要协调
  • 用户访问审查应该包括 Supabase
  • 事件响应计划应该考虑单点登录（SSO）的依赖
  • 在你们组织的操作手册中记录 SSO 配置

最终核对清单 #

🌐 Final verification checklist

在向你的组织推行单点登录(SSO)之前：

🌐 Before rolling out SSO to your organization:

身份验证和登录流程：

  • IdP 发起的登录可以从 IdP 仪表板进行
  • SP 发起的登录有效（如果域已配置）
  • 为你的使用场景选择了合适的登录流程
  • 域配置正确（或故意为空，仅用于 IdP）
  • 多个环境可以正确路由（如果使用多个提供商的话）

自动加入功能：

  • 自动加入会将用户添加到正确的组织（如果已启用）
  • 自动加入的用户会获得正确的默认角色
  • 自动加入在首次登录时生效（不仅在注册时生效）
  • 启用此功能后，现有用户会自动加入
  • 自动加入是幂等的（不会有重复成员）
  • 自动加入适用于 IdP 启动（无需域名）
  • 不匹配的域被排除（如果使用 SP 发起）

邀请:

  • 需要 SSO 的邀请可以正常使用
  • 非单点登录邀请可以正常使用
  • 邀请类型可以被明确选择
  • SSO 不匹配错误很明显

安全与访问控制：

  • 至少存在一个非SSO的所有者账户
  • 非单点登录账户可以成功登录
  • 非单点登录凭据已安全存储
  • 已了解并测试 SSO 账户删除限制
  • 已验证安全删除行为（如果已测试）

配置：

  • 证书到期日期已用日历提醒记录
  • 团队已收到单点登录可用通知
  • 提供登录说明（IdP 瓷贴和/或 supabase.com）
  • 回滚计划已记录
  • 支持联系方式可用

测试完成：

  • 已用多个用户账户测试
  • 测试了两种登录流程（如果都启用的话）
  • 自动加入行为已验证
  • 已确认 SSO 账户限制
  • 域名限制已验证（如适用）
  • 多环境隔离已验证（如果使用多个提供商的话）

需要帮忙吗？ #

🌐 Need help?

如果你遇到本指南未涵盖的问题，请联系你的 Supabase 客户支持获取帮助。联系时，请提供：

🌐 If you encounter issues not covered in this guide, contact your Supabase support representative for assistance. When reaching out, include:

  • 组织名称和网址
  • 单点登录提供商类型（Okta、Azure AD、Google Workspace 等）
  • 具体错误信息
  • 你已经尝试过的步骤
  • 这个问题是影响所有用户还是只是特定的人