从Auth0迁移至Supabase Auth
了解如何将用户从Auth0迁移过来
您可以将用户从 Auth0 迁移至 Supabase Auth。
为生产环境应用更换认证提供商是一项重要操作,可能会影响应用的各个方面。请提前阅读本指南并制定计划,以处理关键的迁移步骤和可能出现的问题。通过提前规划,可以实现平稳安全的认证迁移。
准备工作
在开始之前,请考虑以下问题的答案。这些问题将帮助您决定是否需要迁移以及采用哪种策略:
- 随着用户规模增长,认证提供商的成本如何变化?
- 新的认证提供商是否提供所有必需功能?(例如 OAuth、密码登录、安全断言标记语言(SAML)、多因素认证(MFA))
- 迁移期间是否可以接受服务中断?
- 在终止旧认证提供商之前,您的迁移时间表是怎样的?
迁移策略
根据您的评估,可以选择以下策略之一:
- 滚动迁移
- 一次性迁移
策略 | 优点 | 缺点 |
---|---|---|
滚动迁移 |
|
|
一次性迁移 |
|
|
迁移步骤
身份验证提供商迁移需要两个主要步骤:
- 从旧提供商(Auth0)导出用户数据
- 将数据导入新提供商(Supabase Auth)
第一步:导出用户数据
Auth0 提供两种导出用户数据的方法:
- 使用 Auth0 数据导出功能
- 使用 Auth0 管理 API。该端点有速率限制,因此您可能需要分批次导出用户。
如需导出密码哈希和 MFA 因素,请联系 Auth0 支持团队。
第二步:将用户导入 Supabase Auth
导入用户的步骤取决于您支持的登录方式。
请参阅以下部分了解如何导入:
基于密码的登录方式
对于使用密码登录的用户,我们推荐采用混合迁移方法以减少停机时间:
- 新用户使用 Supabase Auth 进行注册
- 现有用户通过一次性迁移完成
注册新用户
使用 Supabase Auth 的登录方法注册新用户。
将现有用户迁移至 Supabase Auth
将现有用户迁移至 Supabase Auth 需要两个主要步骤:首先确定需要迁移的用户,然后使用 Supabase 管理端点创建他们的账户。
-
获取您的 Auth0 用户导出数据和密码哈希导出列表
-
筛选使用密码登录的用户
- 在用户对象的
identities
字段下,这些用户的 provider 会是auth0
。在同一个身份对象中,您可以找到他们的 Auth0user_id
- 通过将 Auth0
user_id
与密码哈希导出中的oid
字段比对,确认用户是否有对应的密码哈希
- 在用户对象的
-
使用 Supabase Auth 的 admin create user 方法在 Supabase Auth 中重建用户。如果用户有已验证的邮箱或手机号,将
email_confirm
或phone_confirm
设为true
12345const { , } = await ...({ : 'valid.email@supabase.io', : '$2y$10$a9pghn27d7m0ltXvlX8LiOowy7XfFw0hW0G80OjKYQ1jaoejaA7NC', : true,})支持的密码哈希算法
Supabase 支持 bcrypt 和 Argon2 密码哈希。
如果您只有明文密码而非哈希值,可以直接提供密码。Supabase Auth 会为您处理密码哈希(密码始终以哈希形式存储)。
1234const { , } = await ...({ : 'valid.email@supabase.io', : 'supersecurepassword123!',}) -
要让迁移的用户登录,使用 Supabase Auth 的 sign in methods
为了处理用户未成功迁移的边缘情况,可以使用回退策略确保用户能无缝登录:
- 首先尝试用 Supabase Auth 登录用户
- 如果登录失败,尝试用 Auth0 登录
- 如果 Auth0 登录成功,再次调用 admin create user 方法在 Supabase Auth 中创建用户
无密码登录方法
对于通过电子邮件或手机号的无密码登录,需要检查具有已验证电子邮件地址或手机号的用户。在 Supabase Auth 中创建这些用户时,需将 email_confirm
或 phone_confirm
设置为 true
:
1234const { , } = await ...({ : 'valid.email@supabase.io', : true,})
请检查您的 Supabase Auth 电子邮件配置 并配置用于魔法链接的邮件模板。了解更多请参阅邮件模板指南。
导入用户后,您可以使用 signInWithOtp
方法让他们登录。
OAuth 登录
按照社交登录指南在 Supabase 中配置您的 OAuth 提供商。
对于新用户和现有用户,都可以使用 signInWithOAuth
方法进行登录。这种方式无需预先迁移现有用户,因为用户总是需要通过 OAuth 提供商登录后才能重定向到您的服务。
用户成功完成 OAuth 流程后,您可以通过将他们的社交提供商 ID 映射到 Auth0 来检查该用户是 Auth0 中的新用户还是现有用户。Auth0 将社交提供商 ID 存储在用户 ID 中,格式为 provider_name|provider_id
(例如 github|123456
)。了解更多请参阅 Auth0 身份文档。
Auth0 与 Supabase Auth 的映射关系
每个认证提供商(Auth provider)都有自己独特的用户信息跟踪模式。
在 Supabase Auth 中,用户数据存储在项目的 auth
模式下的数据库中。每个用户都有一个身份标识(除非是匿名用户),代表他们可以通过 Supabase 使用的登录方式。这通过 auth.users
和 auth.identities
表来体现。
映射用户元数据和自定义声明
Supabase Auth 提供了两个字段用于映射来自 Auth0 的用户特定元数据:
auth.users.raw_user_meta_data
:用于存储用户可更新的非敏感元数据(如全名、年龄、喜欢的颜色)auth.users.raw_app_meta_data
:用于存储用户不可更新的非敏感元数据(如定价计划、访问控制角色)
这两个列都可以通过管理员用户方法访问。要创建带有自定义元数据的用户,可以使用以下方法:
123456789const { , } = await ...({ : 'valid.email@supabase.io', : { : 'Foo Bar', }, : { : 'admin', },})
这些字段会暴露在用户的访问令牌 JWT 中,因此不建议在这些字段中存储过多的元数据。
这些字段以 jsonb
类型存储在 auth.users
表的列中。可以通过管理员方法 updateUserById
更新这两个字段。如果希望允许用户更新自己的 raw_user_meta_data
,可以使用 updateUser
方法。
如果需要存储大量用户特定元数据,建议在私有模式中创建自己的表,使用用户 ID 作为外键:
12345create table private.user_metadata ( id int generated always as identity, user_id uuid references auth.users(id) on delete cascade, user_metadata jsonb);