登录方式与会话机制：邮箱、OAuth、Magic Link 与匿名

登录方式与会话机制：邮箱、OAuth、Magic Link 与匿名

Supabase Auth 支持多种登录方式，每种都有各自的适用场景与权衡。本节介绍最常用的四类——邮箱密码、第三方 OAuth、Magic Link（魔法链接）、匿名登录——并讲解它们如何与会话机制衔接。

一、邮箱与密码登录

最经典的登录方式：用户用邮箱注册并设置密码，之后用「邮箱 + 密码」登录。

• 适用场景：面向大众的通用应用，尤其是需要稳定账号体系的业务。
• 优点：认知门槛低，几乎所有用户都熟悉。
• 注意事项：
  • 密码由 Auth 服务加密存储，应用层不应接触明文密码。
  • 通常配合邮箱验证流程，确保邮箱真实有效。
  • 建议启用密码强度策略与速率限制，防止弱口令与暴力破解。

邮箱密码登录可进一步与 Magic Link、MFA 等组合，提升体验与安全性。

二、第三方 OAuth 登录

用户无需在你的应用注册新账号，而是用已有的第三方账号（如 GitHub、Google、Apple 等）授权登录。

• 适用场景：面向开发者（GitHub）、面向海外大众（Google、Apple）、希望降低注册门槛的应用。
• 优点：用户无需记新密码，转化率高；由可信第三方担保身份。
• 注意事项：
  • 需在第三方平台注册应用，获取客户端凭证并配置到 Supabase。
  • 同一用户首次用某第三方登录会创建新账号；多个第三方如何关联到同一用户，需要设计「账号关联」策略。
  • 第三方可能提供邮箱、头像等基础信息，可同步到用户表。

三、Magic Link（魔法链接）登录

用户输入邮箱后，系统发送一封含「魔法链接」的邮件；用户点击链接即完成登录，全程无需密码。

• 适用场景：希望简化登录、降低密码管理负担的应用，或作为密码登录的补充。
• 优点：无需记忆密码，体验流畅；安全性依赖邮箱本身的控制权。
• 注意事项：
  • 依赖邮件送达，对邮件服务商的可到达性敏感。
  • 链接有时效，过期需重新申请。
  • 不适合对邮件不稳定的地区作为唯一登录方式，常与邮箱密码并列提供。

Magic Link 本质上是「用邮箱所有权代替密码」，把认证转化为「你能收到这封邮件吗」。

四、手机验证码登录

用户输入手机号，系统发送短信验证码，用户输入验证码完成登录。

• 适用场景：移动端为主、对实时性要求高的应用，或国内市场为主的业务。
• 优点：符合移动端使用习惯，验证快速。
• 注意事项：依赖短信网关，存在送达延迟与成本，需防范短信轰炸与验证码滥用。

五、匿名登录

用户无需任何注册即可获得一个「匿名身份」，先把应用用起来；之后再绑定邮箱或第三方，升级为正式账号，且已有数据不丢失。

• 适用场景：希望让用户「先体验、后注册」的应用，如工具类、内容浏览类产品。
• 优点：极大降低初次使用门槛，提升转化。
• 注意事项：匿名身份通常有有效期或设备绑定，需引导用户及时升级为正式账号，否则数据可能丢失。

会话机制：登录之后维持登录态

无论哪种登录方式，认证成功后系统都会签发令牌，并在客户端建立会话（session）。会话的核心组成：

• 访问令牌（Access Token）：每次请求携带，用于证明身份，有效期较短。
• 刷新令牌（Refresh Token）：有效期较长，用于在访问令牌过期后换取新的访问令牌，避免要求用户重新登录。
• 用户信息：当前登录用户的基本资料与标识。

客户端库通常会自动管理这套会话：登录后安全存储令牌，请求时自动附带令牌，过期时自动用刷新令牌续期。开发者多数时候只需关心「是否已登录」「当前用户是谁」。

各方式的选型建议

实际上这些方式可以并存——你可以同时开启邮箱、GitHub、Google，让用户自选。Supabase 会把它们关联到统一的用户体系。

小结

邮箱密码、OAuth、Magic Link、手机验证码、匿名登录各有适用场景，可按需组合启用。它们在认证成功后都汇入同一套会话机制，由访问令牌与刷新令牌维持登录态。下一节我们深入令牌本身，理解 JWT 的工作原理与会话管理细节。