Expo 和 React Native 应用中的身份验证
了解如何在 Expo 项目中设置身份验证。
身份验证是现代应用中90%到95%的关键部分。本指南解释了常见的方法、模式和解决方案，帮助你在Expo应用中实现身份验证。
🌐 Authentication is a critical part of 90 to 95 percent of modern apps. This guide explains common methods, patterns, and solutions to help you implement authentication in your Expo app.
信息 简短总结：认证很复杂。如果你想跳过复杂的部分，可以直接查看认证解决方案部分，那里有现成的方案。否则，请继续阅读。
实现身份验证不仅仅是编写客户端代码。你还需要管理服务器请求、密码流程、像 Google 或 Apple 这样的第三方提供商、电子邮件处理以及 OAuth 标准。它可能很快变得复杂。
🌐 Implementing authentication involves more than writing client-side code. You'll need to manage server requests, password flows, third-party providers like Google or Apple, email handling, and OAuth standards. It can get complex quickly.
有几种类型的身份验证方法。有些方法简单有效，而有些方法则能提供更好的用户体验，但需要更多的工作。让我们来看看最常用的方法以及如何实现它们。
🌐 There are several types of authentication methods. Some are simple and effective, while others offer a better user experience but require more work. Let's look at the most common approaches and how you can implement them.
导航授权流程
🌐 Navigation auth flow
让我们从基础开始：任何认证系统都需要将公开屏幕（例如登录或注册）与受保护屏幕（例如主页或个人资料）分开。在导航层面，这归结为一个简单的检查：用户是否已认证？
🌐 Let's start with the basics: any authentication system needs to separate public screens (such as login or signup) from protected screens (such as home or profile). At the navigation level, it comes down to a simple check: is the user authenticated?
首先，你可以用一个硬编码的布尔值，比如 isAuthenticated = true 来模拟，并围绕它构建你的导航逻辑。一旦一切正常工作，你就可以接入真正的身份验证流程。
🌐 To begin, you can simulate this using a hardcoded boolean value, like isAuthenticated = true, and build your navigation logic around it. Once everything is working, you can plug in your real authentication flow.
使用 Expo 路由
Expo Router v5 引入了受保护的路由，可以防止用户在未认证的情况下访问某些页面。此功能在客户端导航中效果良好，并简化了你的设置。
🌐 Expo Router v5 introduced protected routes, which prevent users from accessing certain screens unless they are authenticated. This feature works well for client-side navigation and simplifies your setup.
如果你使用的是较旧版本的 Expo Router，你可以改用 重定向。重定向可以实现相同的效果，但需要更多的手动配置。在 Expo Router v5 中，为了向后兼容，重定向仍然受支持。
🌐 If you're using an older version of Expo Router, you can use redirects instead. Redirects provide the same result but require a bit more manual configuration. They are still supported in Expo Router v5 for backward compatibility.
学习如何使用 Expo Router 实现身份验证流程
Expo Router 和 React Navigation 都为你提供了灵活的工具，以根据用户是否已登录来实现受保护的导航。
🌐 Both Expo Router and React Navigation give you flexible tools to implement protected navigation based on whether the user is logged in.
电子邮箱和密码
🌐 Email and password
电子邮件和密码是在为应用添加身份验证时的常用选项。
🌐 Email and password is a popular option when adding authentication to your app.
为了使这个流程对用户友好，你还需要实现忘记密码和重置密码功能，以便那些丢失账户访问权限的用户可以恢复账户。
🌐 To make this flow user-friendly, you also need to implement forgot password and reset password functionality so users who lose access to their accounts can recover them.
如果你想要更快捷的解决方案，几种服务提供内置的邮箱和密码认证，包括 Clerk、Supabase、Cognito、Firebase 和 Better Auth。这些大多数服务都有慷慨的免费额度，但如果你的应用快速增长，评估价格是个好主意。
🌐 If you want a quicker solution, several services offer built-in email and password authentication, including Clerk, Supabase, Cognito, Firebase, and Better Auth. Most of these have generous free tiers, but it is a good idea to evaluate pricing if your app grows quickly.
这些服务最大的优势是易于集成。它们通常提供清晰的文档、入门套件和预制组件，节省你的时间。
🌐 The biggest advantage of these services is their ease of integration. They usually offer clear documentation, starter kits, and prebuilt components that save you time.
安全清单（OWASP）和商店审核注意事项
如果你自己在构建这个流程，请务必查看 OWASP 的 认证备忘单。其中概述了密码长度、加密、恢复、安全存储等方面的最佳实践。
🌐 If you're building this flow yourself, be sure to review the Authentication Cheat Sheet by OWASP. It outlines best practices for password length, encryption, recovery, secure storage, and more.
信息 添加邮箱和密码认证通常足以通过 App Store 和 Play Store 的审核。你可以先使用这种方式提交你的应用。如果你包含“使用 Google 登录”，Apple 可能会拒绝你的应用，除非你也支持“使用 Apple 登录”。同样的规则在 Google Play 上也是相反的。
一个演示使用 Better Auth 进行邮箱和密码认证的示例。
无密码登录
🌐 Passwordless login
无密码登录无需用户创建或记住密码。相反，他们在注册时提供邮箱地址或手机号。然后你的应用会向他们的邮箱或设备发送魔法链接或一次性验证码 (OTP)。对于大多数用户来说，这是一种更流畅的体验，并且在注册过程中降低了阻力。
🌐 Passwordless login removes the need for users to create or remember a password. Instead, they provide their email address or phone number during registration. Your app then sends a magic link or one-time passcode (OTP) to their inbox or device. This is a smoother experience for most users and reduces friction during onboarding.
魔法链接
使用魔法链接时，用户会收到一封包含链接的电子邮件，该链接会将他们重定向回你的应用。如果一切正常，用户会话将被验证并建立。
🌐 With magic links, the user receives an email containing a link that redirects them back into your app. If everything works correctly, the session is verified and established.
这里的一个关键细节是深度链接。由于用户会离开应用去查看他们的电子邮件，链接必须能够打开你的应用并引导他们到正确的界面。如果深度链接失败，会话无法验证，登录流程也会中断。
🌐 A key detail here is deep linking. Since users leave the app to check their email, the link must open your app and route them to the correct screen. If deep linking fails, the session cannot be validated, and the login flow breaks.
如果你使用的是 Expo Router，深度链接通常会自动处理（适用于大多数情况）。你通常不需要进行额外配置就可以让魔法链接正常工作，这使得这种方法更容易采用。请参阅 链接到你的应用 了解更多信息。
🌐 If you're using Expo Router deep linking is handled automatically (for most cases). You usually don't need to configure anything extra to make magic links work properly, which makes this approach even easier to adopt. See Linking into your app to learn more.
React Navigation 也支持深度链接，但你需要手动配置它。更多细节请参阅其 深度链接指南。
一次性密码 (OTP)
魔法链接的另一种选择是通过电子邮件或短信发送一次性密码。用户不是点击链接，而是复制代码并手动返回应用输入。这必须在代码过期之前的特定时间窗口内完成。
🌐 An alternative to magic links is sending a one-time passcode by email or SMS. Instead of clicking a link, the user copies the code and manually returns to the app to enter it. This must happen within a specific time window before the code expires.
这里没有涉及深度链接。用户可以自行掌控流程，并且必须自己返回应用。
🌐 There's no deep linking involved here. The user stays in control of the flow and must return to the app themselves.
幸运的是，更新版本的Android和iOS会自动检测收到的消息中的验证码。这会在键盘上方提供自动填充建议，让用户只需轻点一下即可输入验证码。当功能正常工作时，体验是无缝的。
🌐 Fortunately, newer versions of Android and iOS automatically detect passcodes in incoming messages. This enables autofill suggestions above the keyboard, allowing users to enter the code with a single tap. When this works, the experience is seamless.
信息 魔法链接和一次性密码都是有效的 Google Play 商店和苹果 App Store 评论身份验证方法。你可以仅使用其中任何一种方法提交应用并获得批准，即使在添加社交或 OAuth 登录选项之前也是如此。
OAuth 2.0
要让你的用户使用他们在 Google、Apple、GitHub 等服务上的现有账户登录，你可以使用 OAuth 2.0。
🌐 To let your users log in using their existing accounts from services like Google, Apple, GitHub, and more, you can use OAuth 2.0.
OAuth 2.0 是一种广泛使用的安全协议，它允许你的应用在无需处理密码的情况下访问用户在其他服务上的信息。它让用户可以一键登录，节省时间，建立信任，并免去了管理密码的麻烦。
信息 OAuth 流程可能比较复杂。如果你想要一个简单的集成，大多数提供商都会提供处理所有事务的 SDK 和服务。你可以在 认证解决方案 部分了解更多信息。
如果你希望获得完全的控制权或想了解 OAuth 在底层是如何工作的，以下部分将展示如何使用 Expo 自行实现完整的 OAuth 流程。
🌐 If you are looking for full control or want to understand how OAuth works under the hood, the following sections show how to implement a complete OAuth flow yourself using Expo.
OAuth 的工作原理
🌐 How OAuth works
OAuth 的工作原理是引入一个授权服务器，作为安全的中间人。用户不会将密码直接提供给你的应用，而是通过这个服务器登录，并批准访问特定的数据（例如他们的名称或邮箱）。服务器随后会发放一个临时代码，你的应用可以用它来交换一个安全的访问令牌。
🌐 OAuth works by introducing an authorization server that acts as a secure middleman. Instead of giving your app their password, users log in through this server and approve access to specific data (like their name or email). The server then issues a temporary code, which your app can exchange for a secure access token.
一旦你理解了这个模式，你就可以将其应用到任何提供商。Google、Apple 或 GitHub 的设置将遵循相同的一般步骤。
🌐 Once you understand this pattern, you can apply it to any provider. The setup for Google, Apple, or GitHub will follow the same general steps.
使用 Expo API 路由的自定义 OAuth
🌐 Custom OAuth with Expo API Routes
前面的图表展示了 OAuth 流程的高级概览。然而，客户端从用户那里获取授权许可的首选方法是使用授权服务器作为中介，这正是你可以使用 Expo API 路由构建的功能。
🌐 The previous diagram shows a high-level overview of the OAuth flow. However, the preferred method for a client to obtain an authorization grant from the user is to use an authorization server as an intermediary, which is exactly what you can build using Expo API Routes.
下图更详细地说明了这一流程：
🌐 The following diagram illustrates this flow in more detail:
Expo 让你可以在应用中直接实现完整的 OAuth 流程，使用:
🌐 Expo lets you implement the entire OAuth flow directly in your app using:
一些提供商提供本地 API，以便直接在应用内处理登录流程。谷歌在 Android 上提供本地的“使用 Google 登录”体验。如果你正在寻找本地实现，请参阅 Google 身份验证指南。苹果提供“使用 Apple 登录”，它在 iOS 上使用本地底部弹出和 Face ID。请参阅 expo-apple-authentication 参考。
🌐 Some providers offer native APIs to handle the sign-in flow directly within the app. Google offers a native Sign in with Google experience on Android. If you're looking for a native implementation, see the Google authentication guide. Apple provides Sign in with Apple, which uses a native bottom sheet and Face ID on iOS. See expo-apple-authentication reference.
以下设置让你可以全面控制在 Android、iOS 和网页上的登录体验。
🌐 The following setup gives you full control over the login experience across Android, iOS, and web.
什么是 Expo API 路由？
Expo Router API 路由 允许你在 Expo 应用中直接编写服务器端逻辑。你可以定义处理请求的函数，就像在 Express 或 Next.js 后端一样，无需外部服务器。
这使得在你的应用中直接安全地处理身份验证流程中的敏感部分变得容易，例如授权码交换。由于这些路由运行在服务器上，你可以安全地管理密钥、颁发 JWT 并验证令牌。
🌐 This makes it easy to securely handle sensitive parts of the auth flow, like the authorization code exchange, directly within your app. Since these routes run on the server, you can safely manage secrets, issue JWTs, and validate tokens.
信息 你基本上是在构建一个轻量级的自定义认证服务器，范围仅限于你自己的应用，所有操作都使用你的 Expo 项目。
什么是 Expo AuthSession？
Expo AuthSession 是一个客户端包，帮助你打开网页浏览器或原生弹窗来启动 OAuth 登录流程。它负责处理重定向、解析授权响应，并将用户带回你的应用。
这是启动流程并在用户授权访问后与你的 API 路由通信的工具。更多信息请参见 使用 OAuth 或 OpenID 提供商进行身份验证。
🌐 It's the tool that kicks off the flow and talks to your API Route after the user authorizes access. See Authentication with OAuth or OpenID providers for more information.
此设置允许你：
🌐 This setup lets you:
- 使用 AuthSession 开始登录流程
- 在你的 API 路由中接收授权码
- 安全地将代码兑换为令牌
- 使用你自己的逻辑生成自定义 JWT
- 将该令牌返回给客户端
- 使用 Cookie（网页）或 JWT（原生）存储会话
- 使用 EAS 托管立即部署（免费开始）
以下教程涵盖了在 Android、iOS 和网页上实现 OAuth 的方法，包括如何创建和验证自定义 JWT、管理会话以及保护 API 路由。如果你对这个流程不熟悉，建议从 Google 教程开始学习。
🌐 The following tutorials cover implementing OAuth on Android, iOS, and web, including how to create and verify custom JWTs, manage sessions, and protect API routes. If you're new to this flow, we recommend starting with the Google tutorial.
了解如何使用 Expo Router API 路由实现 Google 登录
学习如何实现苹果登录
OAuth 之后的会话管理
安全地处理 OAuth 流程只是开始。一旦用户通过身份验证，你还需要考虑如何存储、恢复和验证他们的会话。
🌐 Handling the OAuth flow securely is just the beginning. Once the user is authenticated, you need to think about how to store, restore, and validate their session.
这包括：
🌐 This includes:
- 在客户端安全地存储会话
- 在应用重启时恢复它
- 保护你的 API 路由，使只有经过身份验证的用户才能访问
传统上，cookies 用于在网页上存储会话，而 JSON Web Tokens (JWTs) 则在本地应用中很常见。
🌐 Traditionally, cookies are used to store sessions on the web, while JSON Web Tokens (JWTs) are common in native applications.
以上教程准确演示了如何处理这个问题。在从像 Google 或 Apple 这样的提供商接收 ID 令牌后，你可以使用 Expo API 路由在服务器上生成自定义 JWT。
🌐 The above tutorials demonstrate exactly how to handle this. After receiving the ID token from a provider like Google or Apple, you generate a custom JWT on the server using Expo API Routes.
这让你可以完全控制会话，包括：
🌐 This gives you full control over the session, including:
- 使用各提供商之间一致的字段来构建有效负载
- 自定义过期时间
- 使用密钥对令牌进行签名，以便你的服务器稍后可以验证它
一旦创建了令牌：
🌐 Once the token is created:
- 对于 Android 和 iOS 应用，你可以使用
expo-secure-store安全地存储它 - 对于网页应用，你可以将其设置为安全的 Cookie 以维持会话
在每次请求中，令牌都会被发送回你的服务器，在那里你可以验证签名并检查过期时间。如果一切正常，你就可以继续处理请求。
🌐 On every request, the token is sent back to your server, where you verify the signature and check the expiration. If everything checks out, you continue processing the request.
此会话模型保持你的后端无状态、可扩展且安全，并在各个平台上始终如一地工作。
🌐 This session model keeps your backend stateless, scalable, and secure, and works consistently across platforms.
所有这些内容都在上面链接的视频教程中涵盖，包括：
🌐 All of this is covered in the video tutorials linked above, including:
- 生成和验证自定义 JWT
- 使用安全存储和 cookies 处理会话存储
- 使用身份验证逻辑保护 API 路由
身份验证解决方案
🌐 Auth solutions
如果你不想从零构建完整的身份验证系统，一些服务提供了内置解决方案，并且对 Expo 提供一流的支持。以下是一些最受欢迎的选项：
🌐 If you prefer not to build a full authentication system from scratch, several services offer built-in solutions with first-class support for Expo. Here are some of the most popular options:
更好的认证
BetterAuth 是一个为开发者打造的现代开源认证提供者。它可以与 Expo 无缝集成，并且他们提供了一个指南，展示如何与 Expo API Routes 配合使用，以实现完全控制。它能够很好地与任何提供者配合使用，并且可以轻松通过 EAS Hosting 部署。
职员
Clerk 是一个功能强大、功能全面的身份验证服务，支持优秀的 Expo 集成。它包括电子邮件/密码、验证码、魔法链接、OAuth 提供商，甚至还有通行密钥。他们还提供一个原生的 Expo 模块，为你处理大部分集成工作。
苏帕贝斯
Supabase 提供完整的后端平台，包括一个内置的身份验证服务，可与任何 OAuth 提供商配合使用。它与 Expo 应用集成良好，还支持电子邮件、魔法链接等功能。
认知
AWS Cognito 是亚马逊用于管理用户池和身份的解决方案。它可以与其他 AWS 服务无缝连接，并且可以通过 AWS Amplify 集成到 Expo 应用中。虽然需要更多的配置，但它稳定且可扩展。
Firebase 身份验证
Firebase 身份验证 是 Google 的身份验证平台，支持电子邮件、魔法链接和 OAuth 提供商。它可以通过 react-native-firebase 与 React Native 一起使用，并与 Expo 开发构建兼容。
现代方法
🌐 Modern methods
一旦你有了一个可用的身份验证系统，就可以通过添加可选但强大的增强功能来提升用户体验，例如生物识别和密码密钥。这些功能为你的登录流程增加了便利性、信任度和速度。
🌐 Once you have a working authentication system in place, you can improve the user experience by adding optional but powerful enhancements like biometrics and passkeys. These features add convenience, trust, and speed to your login flows.
生物识别
像 Face ID 和 Touch ID 这样的生物识别技术可以在建立有效会话后用于解锁应用或确认身份。它们本身并不是认证方法，而是作为本地门控，使重新认证更快更安全。
🌐 Biometrics like Face ID and Touch ID can be used to unlock the app or confirm identity after a valid session is established. These are not authentication methods on their own, but act as a local gate that makes re-authentication faster and more secure.
React Native 通过像 expo-local-authentication 或 react-native-biometrics 这样的库提供对生物识别 API 的访问。
🌐 React Native provides access to biometric APIs through libraries like expo-local-authentication or react-native-biometrics.
通行密钥
通行密钥 是一种用于登录应用和网站的新型无密码方式。由苹果、谷歌和微软支持，它们使用平台级加密和生物识别技术来在无需密码的情况下验证用户身份。
密钥提供了无缝且安全的体验，但在注册之前，用户必须已经通过身份验证。如果你不使用提供商为你处理密钥，还需要额外的配置。
🌐 Passkeys offer a seamless and secure experience, but they require a user to already be authenticated before registering one. They also require extra configuration if you're not using a provider that handles them for you.
- React Native 密钥支持：
react-native-passkeys - 使用 Clerk 的原生密钥支持：Expo 的 Clerk 密钥
建议
🌐 Recommendations
本指南涵盖了很多内容，从基础的电子邮件和密码流程到完全自定义的 OAuth 实现、会话管理，以及像生物识别和安全密钥这样的现代方法。并非所有内容都需要一次性实现。
🌐 This guide covers a lot of ground, from basic email and password flows to fully custom OAuth implementations, session management, and modern methods like biometrics and passkeys. Not all of these need to be implemented at once.
在很多情况下，从简单开始是最好的方法。发布一个带有魔术链接或一次性验证码的电子邮件认证的应用，通常足以通过 App Store 审核流程，并开始从真实用户那里收集反馈。
🌐 In many cases, starting simple is the best approach. Shipping your app with something like email authentication using a magic link or one-time passcode is often more than enough to get through the App Store review process and start collecting feedback from real users.
也就是说，如果你正在开发一个从第一天起就预计有高流量的应用，或者需要在各个平台上支持无障碍的登录，那么从一开始就在认证流程上投入更多，可以带来很大不同。这有助于从一开始就提高用户的引导、信任度和留存率。
🌐 That said, if you're building an app where you expect high traffic from day one or need to support sign-in across platforms with minimal friction, investing in a more complete authentication flow early on can make a big difference. It can help improve user onboarding, trust, and retention right from the start.
OAuth、生物识别和密钥等现代解决方案并非必需，但一旦你的核心系统到位，它们可以成为极好的补充。
🌐 Modern solutions like OAuth, biometrics, and passkeys are not required, but they can be excellent additions once your core system is in place.
关键在于构建符合你当前需求的身份验证，同时保持足够的灵活性以配合你的产品发展。
🌐 The key is to build authentication that fits your current needs, while staying flexible enough to grow with your product.