Flask API+React Native移动端Google OAuth2登录后JWT安全传递方案咨询

背景与当前流程 #

我用Flask搭建了API服务器，React Native开发移动端客户端，应用支持邮箱/密码登录和Google登录，当前Google认证流程如下：

• 用户点击Sign in with Google按钮
• 前端跳转至API的/api/google/authorize端点，该端点重定向到Google登录页面，用户完成登录并授权应用访问账户信息
• 登录成功后，通过/api/google/callback端点重定向回API
• 回调端点用Google返回的授权码换取access token和ID token，若用户此前不存在则自动创建账户
• 目前卡在最后一步：如何安全地将ID token（后续还需传递refresh token）返回给前端，用于后续API请求的认证与授权

现有方案疑问 #

我梳理了两种可能的方案，但各有顾虑：

1. 二次授权码流转：生成一个临时代码，通过重定向的查询参数发送给前端，前端再调用另一个API端点用该代码换取令牌对。但感觉这重复了OAuth流程——已经用了Google的授权码，还要额外实现安全校验确保只有当前用户能使用这个临时代码，显得冗余。
2. 自定义URI Scheme/Deep Linking：使用myapp://这类自定义URI替代https://，将令牌作为查询参数传递给前端。我更倾向这个方案，因为它安全灵活，代码改动量小，只需前端添加监听自定义URI的逻辑，但不确定是否存在潜在弊端。

这是我首次设计移动端认证流程（此前仅开发过Web应用），想了解是否还有其他可考虑的方案。

方案分析与补充建议 #

自定义URI Scheme的潜在风险 #

你倾向的这个方案确实有几个需要注意的细节：

• URI劫持风险：如果其他恶意APP注册了相同的自定义Scheme，可能会拦截回调请求窃取令牌。不过现在iOS和Android都有更安全的替代方案：Android的App Links、iOS的Universal Links，通过HTTPS域名绑定APP，能避免这类劫持问题，比纯自定义Scheme更可靠。
• 令牌日志泄露：虽然移动端URI的日志暴露概率比Web端低，但部分系统日志或第三方工具仍可能记录URI内容，导致令牌泄露。可以考虑把令牌放在URI的fragment部分（例如myapp://callback#id_token=xxx&refresh_token=xxx），因为fragment不会被发送到服务器，也更难被日志捕获。

其他可选方案 #

1. 推送服务传递：在API的回调端点处理完Google授权后，直接通过FCM（Android）或APNs（iOS）把令牌推送给客户端。这种方式完全避开了URI传递的风险，但需要前端集成推送服务，还要处理推送到达时机（比如用户在认证过程中切换APP的情况）。
2. 安全存储中转：利用移动端的Keychain（iOS）或Keystore（Android）这类安全存储，API回调端点将令牌存入对应存储，前端通过轮询API获取认证状态，确认完成后从安全存储中读取令牌。不过这种方式需要控制轮询频率和超时，同时确保存储的访问权限严格受控。
3. 调整为OAuth 2.0 PKCE流程：重构整个认证流程，让前端直接与Google认证服务交互，使用PKCE（Proof Key for Code Exchange）流程获取授权码，再将授权码发送给你的API，由API去换取Google的令牌、创建用户，最后返回自己的应用令牌。这种方式符合原生应用OAuth的最佳实践，减少了中间跳转环节，也降低了令牌传递的风险。

内容的提问来源于stack exchange，提问作者Cristian Gira