使用 Expo、Clerk 和 iOS 登录 Google OAuth — 终极揭秘

Source: Dev.to

Client ID + Client Secret：介绍名片（以及身份凭证）

把 Google 和 Clerk 想象成两家公司。

• Client ID – 你的应用的“名片”（公开身份）。
• Client Secret – 你的应用的“密封信/私人印章”（私密凭证）。

当你把这些从 Google 粘贴到 Clerk 时，你实际上是在说：

“Clerk，当我的应用说‘我是你期待的 Google 应用’时，这里是官方的身份证明和私密凭证，这样你就能相信真的就是我。”

为什么重要：没有这层正式的介绍，Clerk 无法自信地以你的应用身份与 Google 通信，而 Google 也不知道该使用哪套 OAuth 应用配置规则。

Redirect URL 必须匹配：接力赛的交接棒

OAuth 就像接力赛：

1. 你的应用把跑者送到 Google（登录页面）。
2. Google 完成它的段落（用户认证）。
3. Google 必须 把交接棒交回 给正确的下一位跑者。

那个“交接点”就是 Redirect URL（重定向 URL）。

规则：Google 被允许交接棒的重定向 URL 必须与你的应用/Clerk 所期待的相匹配。

这就是为什么要检查 两个仪表盘：

• Google Cloud Console：“这些是允许的交接地址。”
• Clerk：“这是我期待的交接地址。”

如果不匹配，Google 会拒绝交接（因为可能存在安全风险）。

iOS 必须识别重定向 URL：Google → iOS → Your App

在移动端，接力棒不会自动直接返回你的应用。实际流程是：

Google → iOS（系统） → Your App

因此 iOS 需要知道：

“当我看到一个看起来像 这样 的 URL 时，哪个已安装的应用应该接收它？”

这些正是用来做这些的：

• app.json scheme – 注册你的应用拥有的“特殊地址格式”（就像认领一个邮箱）。
• Expo Linking – 帮助你的应用监听并解析传入的重定向，以便继续登录流程。

通俗来说：app.json 告诉 iOS 哪个应用拥有该 URL，Linking 则帮助你的应用打开信封并读取 Google 返还的内容。

Secure Store：赛后把接力棒锁进保险箱

OAuth 成功后，你会在手机上存储一些敏感信息（会话令牌 / 刷新令牌，取决于配置）。

核心概念：移动应用并不是存放明文秘密的安全场所。令牌相当于“你已登录的凭证”。如果被盗，攻击者可以像复制钥匙卡一样重复使用。

解决方案：使用 Secure Store 作为手机内置的保险箱：

• 底层使用 iOS Keychain / Android Keystore。
• 加密并受操作系统保护。

为什么通常需要重新构建：Secure Store 是一种 原生能力。如果你的项目尚未在原生构建中包含它（或你更改了原生配置），就需要一次新的原生构建才能正常使用。

故事化说法：一旦你的应用收到接力棒（令牌），不要把它随意放在桌面上。把它放进酒店保险箱（Secure Store），这样在你不注意时就没人能复制它。

一句话概括

• Client ID/Secret = 你的身份（正式介绍）
• Redirect URL = 接力棒去向（交接点）
• Scheme/Linking = iOS 如何路由（Google → iOS → 应用）
• Secure Store = 结果存放位置（令牌保存在保险箱中）

代码即将跟进…

接下来我会在这里粘贴 React Native 代码… 请关注此处！