05 · 菲律宾 · 社交账号注册/登录技术可行性调研¶

调研日期：2026-06-04 首版 · 2026-07-07 修订（v5，校正定位表述）
调研人：Bob
目标读者：技术（前端 / 后端 / 移动端）
文档性质：纯技术可行性 + 官方文档导读 + 对接要点
定位（重要）：社交登录是在现有「手机号 + 密码」之外新增的一个登录/注册入口，两者并存、非替换——不是用来取消平台密码，而是多给一种选择。核心价值在市场拓展：菲律宾用户本就高度习惯用 Google / Facebook 账号，多一个熟悉入口有望降低注册门槛、提升拉新转化。
结论先行：可实现（§2、§4）；值得做 1～2 周 Google POC（§6.5～6.7）。收益是面向习惯 Google/FB 的菲律宾人多一个熟悉入口、降低注册摩擦、利于获客；代价是 OAuth 工程、IdP 依赖，且须保留现有手机+密码入口。对接见 §3 官方文档索引。

1. 目标与范围¶

1.1 要做什么¶

项	说明
注册	用户点 Google / Facebook → 在 IdP 完成授权 → 在平台自动建号或绑定已有号（作为新增入口，现有手机注册照常保留）
登录	同一社交账号 → 同一平台账号；这条路径无需再设平台密码，但不替换现有手机+密码登录（二者并存）
体验	给已习惯 Google / Facebook 的用户多一个熟悉、少填表的入口；选手机+密码的用户不受任何影响

1.2 方案对比摘要¶

当前为 无 OTP 的手机号 + 自设密码；目标态是在其之上新增 Google / Facebook OAuth 登录选项（并存，非替换——多一种选择，不是砍掉密码）。分场景对比、利弊与是否值得投入见 §6。

2. 技术结论¶

能。 Google 与 Facebook 均提供面向「用第三方账号登录你的网站」的公开 API，底层均为 OAuth 2.0；Google 另提供 OpenID Connect id_token，可直接用于登录态建立。

📘 包网侧：非凡站点配置已描述登录方式可含 Google / Facebook（按当站）（见 08-站点配置 §2.2）——实施前应先确认澎湃 p222 是否只需 开配置 而非全栈自研。

3. 官方文档索引（技术必读）¶

下列链接为对接主入口；实现细节以官方为准，本文只做「读哪篇、做什么」的导读。

3.1 Google（Sign in with Google / OAuth / OIDC）¶

优先级	文档	URL	何时读
P0	Sign in with Google 总览	https://developers.google.com/identity/gsi/web/guides/overview	理解 GIS 与 OAuth 关系、认证/授权分离
P0	获取 Client ID + 同意屏	https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid	创建 Web Client、配 `redirect_uri` / JS origins
P0	OAuth 2.0 Web Server 流程	https://developers.google.com/identity/protocols/oauth2/web-server	后端主导时的标准流程（推荐）
P0	OpenID Connect	https://developers.google.com/identity/openid-connect/openid-connect	`id_token` 校验、`sub` 作为用户主键
P1	OAuth 2.0 政策（硬性约束）	https://developers.google.com/identity/protocols/oauth2/policies	禁止 WebView、HTTPS、首页/隐私政策、scope 最小化
P1	SIWG 最佳实践	https://developers.google.com/identity/siwg/best-practices	认证与授权分离、删号时 revoke token
P2	OAuth 2.0 Playground	https://developers.google.com/oauthplayground/	联调 authorization code / token
移动端	Android Credential Manager	https://developers.google.com/identity/sign-in/android/start	原生 Android
移动端	iOS Google Sign-In	从 GIS 文档链到 Apple 平台指南	原生 iOS

Discovery 文档（硬编码即可）：

https://accounts.google.com/.well-known/openid-configuration

从中读取 authorization_endpoint、token_endpoint、userinfo_endpoint、jwks_uri 等。

优先级	文档	URL	何时读
P0	Facebook Login for Web（JS SDK）	https://developers.facebook.com/docs/facebook-login/web	快速 POC、`FB.login`、`userID`
P0	Manually Build a Login Flow	https://developers.facebook.com/docs/facebook-login/guides/advanced/manual-flow	纯后端 / 无 SDK 时的 redirect + `code` 换 token
P1	Permissions	https://developers.facebook.com/docs/facebook-login/guides/permissions	登录仅需 `public_profile` + `email`（email 默认可选）
P1	Access Tokens	https://developers.facebook.com/docs/facebook-login/guides/access-tokens	token 类型、过期、存储
P1	Create an app	https://developers.facebook.com/docs/development/create-an-app	App ID、OAuth 设置、Valid OAuth Redirect URIs
P2	OIDC Token（可选路径）	https://developers.facebook.com/docs/facebook-login/guides/advanced/oidc-token	若要走标准 OIDC `id_token`（与 Google 对齐）
P2	Login Security	https://developers.facebook.com/docs/facebook-login/security	CSRF `state`、token 校验
P2	Test Login Flow	https://developers.facebook.com/docs/facebook-login/guides/test	测试用户

Graph API 版本：官方 Web 示例当前写 v25.0（文档会随版本更新，以 Dashboard 为准）。

3.3 仅影响「能否接 Facebook Login」的一条开发者政策¶

🔗 Meta Developer Policies（访问 2026-06-04）：

若你要 facilitate or promote online gambling / online real money games，须 事先取得 Meta 书面许可 才能使用 Meta Products（含 Facebook Login）。

技术含义：Facebook Login 可能需 Meta App Review / 书面许可；Google 侧无对等硬性条款（仍须遵守 OAuth 政策）。POC 建议先做 Google，Facebook 并行确认集成审批。

4. 对接方案（按官方推荐路径）¶

4.1 总体原则¶

原则	来源
授权码在服务端换 token	Google Web Server、Facebook `response_type=code`
Client Secret 仅服务端	双方文档均强调
登录 scope 最小化	Google：`openid email profile`；FB：`public_profile,email`
用户主键用 IdP 的 stable id	Google `sub`；Facebook `user_id`（或 OIDC `sub`）
禁止在 App 内 WebView 嵌 Google 授权页	Google OAuth Policies
生产环境 HTTPS redirect	双方要求

4.2 Google：推荐实现（Web Server + OIDC）¶

依据 🔗 OpenID Connect - Server flow 与 🔗 OAuth 2.0 Web Server。

控制台配置¶

Google Cloud Console → Clients 创建 Web application 客户端。
Authorized JavaScript origins：https://你的域名（本地开发可加 http://localhost）。
Authorized redirect URIs：https://你的域名/auth/google/callback（路径自定，须与代码一致）。
Branding / OAuth consent screen：应用名、首页、隐私政策、授权域名（生产需验证，见官方 OAuth verification requirements）。

登录用 scope（仅认证）¶

openid email profile

GIS 文档明确：认证默认 scope 足够，不要在登录时申请 Drive 等 API scope（认证与授权分离）。

请求步骤¶

① 后端生成 state（CSRF，≥128bit 随机，存 session/Redis）
② 浏览器跳转 Google 授权端点（见 Discovery 或固定）：
   GET https://accounts.google.com/o/oauth2/v2/auth
     ?client_id=...
     &redirect_uri=...（URL 编码）
     &response_type=code
     &scope=openid%20email%20profile
     &state=...
     &access_type=online          （仅登录可不存 refresh；要长期静默可 online/offline 再评估）
     &prompt=select_account       （可选：多账号时让用户选）

③ 用户同意后，Google 302 到 redirect_uri?code=...&state=...
④ 后端校验 state，POST 换 token：
   POST https://oauth2.googleapis.com/token
     grant_type=authorization_code
     &code=...
     &client_id=...
     &client_secret=...
     &redirect_uri=...（与②一致）

⑤ 响应含 access_token、id_token（OpenID Connect）
⑥ 验 id_token（必做）：
   - aud == 你的 client_id
   - iss 为 accounts.google.com 或 https://accounts.google.com
   - exp 未过期
   - 用 jwks_uri 验签名（库：google-auth、node-openid-client 等）
⑦ 从 id_token 取 sub（用户唯一 ID）、email、name
⑧ 查 social_accounts(google, sub) → user_id；无则 create user
⑨ 签发你们自己的 session/JWT，Set-Cookie

前端可选：GIS 按钮（仍建议 code 走服务端）¶

加载：https://accounts.google.com/gsi/client（勿自托管）
文档：GIS Overview
FedCM：新站建议按 GIS 文档启用；影响 One Tap / 弹窗行为。
CSP：若站内有 CSP，须放行 accounts.google.com/gsi/*（见 get-google-api-clientid 文档）。
COOP：非 FedCM 时 header 建议 same-origin-allow-popups，避免弹窗白屏。

后端验签参考（逻辑）¶

id_token 载荷关键字段：
  sub   → 绑定主键（必存）
  email / email_verified
  name, picture
  aud, iss, exp, iat

也可用 access_token 调 userinfo（🔗 OIDC 文档 Step 7），但 验签 id_token 是 Server flow 的标准做法。

账号删除¶

🔗 OAuth Policies - Revoke tokens：用户删号时调用 Google revoke 端点撤销授权。

4.3 Facebook：两种对接路径（二选一）¶

路径 A — JS SDK（上手快，适合 POC）¶

文档：https://developers.facebook.com/docs/facebook-login/web

<!-- 仅示例结构，生产勿把 secret 放前端 -->
<script>
  window.fbAsyncInit = function () {
    FB.init({ appId: '{app-id}', cookie: true, version: 'v25.0' });
  };
</script>
<script async defer crossorigin="anonymous" src="https://connect.facebook.net/en_US/sdk.js"></script>

FB.login(function (response) {
  if (response.authResponse) {
    const { accessToken, userID } = response.authResponse;
    // 必须把 accessToken 发到你们后端，由后端 debug_token + 建 session
    fetch('/auth/facebook', {
      method: 'POST',
      body: JSON.stringify({ accessToken, userID }),
    });
  }
}, { scope: 'public_profile,email' });

Dashboard 配置（文档 §1 Enable JavaScript SDK）：

Facebook Login → Settings
Valid OAuth Redirect URIs
Login with JavaScript SDK = Yes
Allowed Domains for JavaScript SDK = 你的 HTTPS 域名

重要：accessToken 不能只在前端信以为真；后端必须：

GET https://graph.facebook.com/debug_token
  ?input_token={用户 accessToken}
  &access_token={app-id}|{app-secret}   ← App Access Token，仅服务端

确认 data.user_id 与前端 userID 一致、data.is_valid。

路径 B — 手动 Redirect（与 Google 对称，适合统一后端）¶

文档：https://developers.facebook.com/docs/facebook-login/guides/advanced/manual-flow

① 生成 state（CSRF）
② 跳转：
   GET https://www.facebook.com/v25.0/dialog/oauth
     ?client_id={app-id}
     &redirect_uri={encode(你的回调 URL)}
     &state={state}
     &response_type=code          ← 服务端换 token，推荐
     &scope=public_profile,email

③ 回调：?code=...&state=...  或取消：?error=access_denied
④ 服务端换 token（client_secret 仅服务端）：
   GET https://graph.facebook.com/v25.0/oauth/access_token
     ?client_id=...
     &redirect_uri=...（与②完全一致）
     &client_secret=...
     &code=...

⑤ 再 debug_token 或 GET /me?fields=id,name,email&access_token=...
⑥ 以 user_id 绑定 social_accounts(facebook, user_id)

redirect_uri 必须在 App Dashboard → Facebook Login → Settings → Valid OAuth Redirect URIs 中 逐字匹配。

路径 C — OIDC（可选，与 Google 模型一致）¶

见 Facebook 文档 OIDC Token with Manual Flow（联调时若 Graph 503 可稍后重读官方页）。思路：拿 OIDC id_token 后按 JWT 验签，用 sub 绑定——与 Google 后端代码可复用同一套「验 JWT → sub」模块。

4.4 统一后端数据模型（Google + Facebook 共用）¶

-- 概念表
social_accounts (
  id,
  user_id,              -- 你们内部用户 ID
  provider,             -- 'google' | 'facebook'
  provider_user_id,     -- Google sub 或 Facebook user_id（唯一）
  email,                -- 可空；仅作展示/找回
  linked_at,
  UNIQUE(provider, provider_user_id)
)

字段	Google	Facebook
`provider_user_id`	JWT `sub`	`user_id` / OIDC `sub`
勿用 email 作主键	email 可变、可缺失	用户可拒绝 email scope

登录态：OAuth 完成后仍建议发 你们自己的 session（Cookie 或 JWT），不要每次请求都带着 Google/FB access_token 调你们 API。

4.5 端到端时序（汇总）¶

sequenceDiagram
    participant U as 用户浏览器
    participant FE as 前端
    participant BE as 后端
    participant IdP as Google或Facebook

    U->>FE: 点击社交登录
    FE->>BE: GET /auth/{provider}/start
    BE->>BE: 生成 state 存 Redis
    BE->>U: 302 到 IdP 授权 URL
    U->>IdP: 登录并同意
    IdP->>U: 302 redirect_uri?code&state
    U->>BE: GET /auth/{provider}/callback
    BE->>BE: 校验 state
    BE->>IdP: code 换 token（服务端）
    BE->>BE: 验 id_token 或 debug_token
    BE->>BE: 查/建 social_accounts + user
    BE->>U: Set-Cookie session

5. 各端实现要点¶

端	Google	Facebook
Web/H5	Redirect 或 GIS 按钮 + 服务端 callback	JS SDK 或 Redirect
Android	Credential Manager / Google Sign-In	Facebook SDK for Android
iOS	ASWebAuthenticationSession + Google	Facebook SDK / Limited Login
共同红线	勿用 WebView 打开 Google 授权页	生产登录页须 HTTPS（FB JS SDK 要求）

移动端与 Web 应共用同一套 social_accounts 与 user_id，仅 OAuth Client 在 Console 按平台 分开注册（Google 政策要求每平台独立 Client）。

6. 对比分析与决策（深度）¶

6.1 用户旅程逐步对比¶

以下对比 同一目标：用户进入站点 → 完成注册 → 日后再次进入。现状为无 OTP 手机+密码；新增的社交入口以 Google 为主（Facebook 流程类似，多一步 Meta 授权页）。注意：社交入口与现有手机+密码入口并存，下表只是对比两条路径的体验差异，不代表要用谁替换谁。

注册（新用户）¶

步骤	现状：手机 + 密码	社交登录
1	打开注册页	打开注册/登录页
2	输入手机号（格式校验）	点击「Continue with Google」
3	输入密码	（浏览器跳转 Google，若已登录 Google 则跳过账号密码）
4	再次输入确认密码	在 Google 同意屏点「继续」（首次授权时）
5	提交	回到站点，后端建号并发 session
用户输入次数（理想路径）	3 个字段 + 2 次密码	0～1 次点击（已登录 Google 时）
用户需记忆	手机号 + 平台密码	只需记得「我用 Google 登的这个站」
典型耗时（📝 经验）	45～90 秒	5～15 秒

可选：社交注册后若业务仍要邀请码，可在 OAuth 回调之后 弹一层（1 个字段），不破坏「无密码」主线。

登录（回访用户）¶

步骤	现状	社交登录
1	打开登录页	打开站点
2	输入手机号	点 Google（或 GIS One Tap 自动提示）
3	输入密码	已登录 Google → 直接回站点带 session
输错成本	密码错 → 重试 / 锁定策略 / 找客服	几乎无「平台密码」输错
换手机	必须记得手机号+密码	新机登录同一 Google 即可

「忘记密码」路径¶

	现状	社交登录
用户忘了什么	常忘平台密码，偶尔忘手机号	走社交入口的用户没有平台密码可忘；忘的是 Google/Facebook 密码，在 IdP 侧找回
你们系统要做啥	重置密码页、客服核验、可能仍要短信	社交路径本身不需要密码重置；但现有密码重置链路照常保留，服务仍用手机+密码的用户
客服工单（📝 推断）	「忘密码」占比高	选择社交入口的那部分用户，其「忘密码」工单转为「Google 登不上」类，量通常更少且边界清晰

注意：若业务保留 提现密码（与登录密码分离），用户仍可能忘提现密码——需在 UI 上区分「登录用 Google」与「提款用提现密码」，避免误解。

技术侧会话¶

	现状	社交登录
凭据	手机号 + 密码哈希校验	`sub` / `user_id` 查绑定表 → 发 session
密码存储	需 bcrypt/argon2、防泄露、重置流	社交路径自身不新增密码；现有密码体系保留，泄露面不因新增入口而扩大
账号唯一性	依赖手机号唯一索引	依赖 `(provider, provider_user_id)` 唯一索引

6.2 社交登录：优点（分维度）¶

体验与转化¶

字段更少：去掉密码、确认密码，降低移动端输入成本（菲律宾用户 97%+ 用手机，🔗 Meltwater 2026）。
认知负担转移：用户已习惯「用 Facebook/Google 登录各种 App」；平台密码是额外记忆项。
回访摩擦低：浏览器/APP 内若 Google session 仍在，接近 一键进站（GIS 支持 One Tap / 自动登录，见 §3.1）。
与无 OTP 策略一致：注册阶段 继续不发短信，不引入新的 OTP 成本。

工程与安全（登录域）¶

社交路径无需额外密码：走 Google/Meta 的用户，其登录凭据由 IdP 托管（撞库、2FA 等由其承担）；这是新增路径的特性，现有密码体系不变、无需拆除。
稳定用户标识：Google sub、Facebook user_id 长期不变，适合做 social_accounts 唯一键；比「用户随便填的手机号」更适合作跨设备同一自然人识别（技术层面）。
协议成熟：OAuth 2.0 / OIDC 有大量库与官方文档（§3）；问题多为配置类，而非协议从零设计。
官方安全基线：state 防 CSRF、授权码仅服务端换 token、Google 禁止 WebView 嵌授权页等，按文档做即可达到行业常规水位。

运维（中长期）¶

针对选择社交入口的那部分用户，其登录密码相关客服（重置、弱密码提示）几乎为零；对仍用手机+密码的用户，维护量不变。
若包网已内置 Google/Facebook 开关（§2），边际开发成本可能远低于自研 16～27 人天。

6.3 社交登录：缺点与代价（分维度）¶

体验与覆盖¶

无法覆盖所有人：无 Google 账号、不愿授权、企业策略禁用社交登录的用户，必须有 备用注册/登录（保留现有手机+密码或邮箱 Magic Link）。
授权屏心理成本：首次使用会看到 Google/Meta 同意屏（应用名、邮箱权限）；部分用户会犹豫——需在按钮文案上说明「仅用于登录」。
IdP 账号问题转嫁：用户 Google 被封、被盗、忘记 Google 密码时，你们无法代替 Google 解决，客服话术需调整。
「永远能登录」不能字面承诺：还取决于你们是否封号、OAuth 配置是否正确、用户是否换了一个从未绑定过的 Google 账号。

工程复杂度¶

新增模块	说明
OAuth Client 生命周期	开发/预发/生产多环境 Client；Secret 轮换
回调路由	`/auth/google/callback` 等必须 HTTPS、与 Console 完全一致
Token 处理	换 code、验 `id_token` 或 `debug_token`、时钟偏移
绑定表	`social_accounts` + 与旧账号合并策略
监控	OAuth 失败率、回调 5xx、`invalid_grant`、同意屏取消率

粗估自研工作量（Web 主路径 + 基础监控，不含 APP 双端深度优化）：

项	人天
Google 全链路	5～8
Facebook 全链路	5～8
账号绑定/合并	3～5
联调 + 监控 + 文档	3～6
合计	16～27

若包网已封装 OAuth，可能降为 配置 + 联调（约 3～10 人天）——以实际接口为准。

运维与依赖¶

强依赖第三方可用性：Google/Meta 故障或区域性网络问题 → 社交入口不可用；必须保留备用登录 并做降级提示。
配置事故影响面大：redirect_uri 错一位、Client Secret 泄露、同意屏域名未验证 → 全站无法社交登录；需要发布 checklist 与快速回滚（切回仅密码登录）。
Facebook 额外不确定性：Meta 开发者政策对真钱类游戏类应用可能要求 App Review / 书面许可（§3.3），导致 Facebook 入口晚于 Google 上线。

与现状相比的「隐性成本」¶

短期内 研发注意力 从其他需求切走 1～2 周做 POC/上线。
测试矩阵变大：新注册、老用户绑社交、双入口并存、取消授权、多设备等。
日志与排障需懂 OAuth 错误码（redirect_uri_mismatch、invalid_client 等）。

6.4 多维对比总表¶

说明：右列是在左列基础上新增社交入口，两条路径并存。表格对比的是「走社交入口时」相较「走手机+密码时」的差异，不是二选一替换。

维度	手机+密码入口（保留）	新增：社交登录入口（与前者并存）
注册步骤数	多（≥3 字段）	少（0～1 次点击为主）
登录步骤数	2 字段	0～1 点击
平台登录密码	必需	该路径不需要（密码入口仍完整保留）
注册短信 OTP	无	仍可无
密码重置系统	需要	照常保留（继续服务密码用户）
客服：忘密码	高相关	走社交的用户几乎不涉及（密码用户不变）
首次开发成本	0	中（16～27 人天自研；包网内置则低）
持续运维	低	中（OAuth 监控、密钥、同意屏）
单点故障	仅你们服务	你们 + IdP
账号标识	手机号	`sub` / `user_id`（更稳定）
用户覆盖率	人人有手机即可	需备用路径补缺口
技术成熟度	极简	行业标准，文档齐全
回滚难度	—	低（隐藏社交按钮即可回现状）

6.5 为什么值得做（决策论据）¶

从 纯注册/登录技术目标 出发，建议投入预研/接入的理由：

贴合菲律宾市场心智（首要理由）
Facebook / Google 在菲律宾渗透极高，用户本就习惯「用社交账号登录各种 App」。多给一个熟悉入口，能直接降低注册门槛，对拉新获客有利——这是做这件事的核心动机，而非工程优化。
对习惯社交账号的用户，摩擦对齐
要这批用户为本平台再单独设一套密码 + 重复确认 + 回访再输，是额外负担；给他们一键社交入口正是 industry 标准解法，不是过度设计。
投入有上限、可验证
用 1～2 周 Google POC 即可验证：回调是否通、session 是否稳、转化是否优于对照组。失败则回滚，沉没成本可控。
纯新增、不推翻现有体系
社交入口与手机+密码并存，是多加一个选项，不替换用户系统；老用户继续密码登录，习惯 Google/FB 的用户走短路径。
与「不用注册 OTP」不冲突
社交登录不增加短信成本，反而减少「为弥补无 OTP 而只能靠手机号标识」带来的体验短板。
可渐进交付
先 Google（政策与文档最顺）→ 再 Facebook → 再 APP SDK；每步独立可上线。

综合判断：作为面向菲律宾市场的拉新 / 降门槛手段——给本就习惯 Google / Facebook 的用户多一个熟悉入口——一次性工程成本可控、可灰度验证、可回滚，值得做深入技术预研（POC），而不是停留在文档层。它是对现有「手机 + 密码」的补充，不是替换。

6.6 什么情况下不值得或应推迟¶

条件	说明
包网完全不可扩展且必须全栈自研，而当下无 2 周研发窗口	成本显性过高
POC 显示授权取消率极高（例如 >40%）且无法通过文案/UX 改善	体验收益存疑
无法保留备用登录入口	部分用户永久流失
团队无人可维护 OAuth（无监控、无 on-call 认知）	配置事故风险不可接受
仅做 H5 且必须在 WebView 内完成 Google 登录	违反 Google 政策，需改架构

以上任一成立，应推迟或缩小范围（例如仅 GIS 按钮 + 仍保留密码）。

6.7 建议投入深度¶

阶段	做什么	产出
文档阅读	§3 P0 官方文档	团队对齐端点与约束
POC（1～2 周）	§4.2 Google Web 全链路 + 备用密码入口保留	成功率、耗时、错误日志
灰度	10% 新用户见 Google 为主按钮	注册完成率、授权取消率
全量	Facebook（§4.3）+ APP	与 Web 共用 `social_accounts`

不建议：无限期调研不写代码；不建议：未 POC 即双端 + 双 IdP 同时全量。

建议顺序：Google POC 通过 → 灰度 → Facebook → APP。

7. 对现有平台的技术风险¶

风险	等级	缓解
redirect_uri / Client ID 配错	高	分环境独立 Client；上线 checklist
Client Secret 进仓库	高	仅服务端环境变量 / Secret Manager
老手机号账号 vs 新社交号一人两号	高	产品规则：「绑定社交」而非重复注册
仅用 email 合并用户	高	必须用 `sub` / `user_id`
双 session 体系	中	社交登录与密码登录走同一 session 中间件
IdP 宕机	中	保留手机号+密码入口；监控 + 告警
用户删号未 revoke Google token	低	删号钩子调 revoke API
提现密码仍独立	中	前台文案区分「登录」与「提款密码」📘 非凡前台设计

8. 推荐前台与实施节奏¶

前台（技术相关 UX）

Continue with Google
Continue with Facebook（审批/POC 通过后）
Sign up with mobile → 现有无 OTP 流程（与社交入口并列、不弃用，面向不愿授权或没有社交账号的用户）

三个入口并存，社交按钮更靠前只是为了贴合菲律宾人习惯、引导拉新，不代表要弱化手机注册。具体排布以灰度转化数据为准。

节奏

阶段	产出
1（1 周）	Google 路径 §4.2 全通 + 监控
2（1 周）	Facebook 路径 §4.3B + 与 Google 共用表结构
3	APP 端复用后端 callback 或 SDK

9. 附录：关键端点速查¶

Google¶

用途	URL
Discovery	`https://accounts.google.com/.well-known/openid-configuration`
授权（常用）	`https://accounts.google.com/o/oauth2/v2/auth`
换 token	`https://oauth2.googleapis.com/token`
撤销	`https://oauth2.googleapis.com/revoke`
GIS 脚本	`https://accounts.google.com/gsi/client`

Facebook（v25.0 示例）¶

用途	URL
授权对话框	`https://www.facebook.com/v25.0/dialog/oauth`
code 换 token	`https://graph.facebook.com/v25.0/oauth/access_token`
校验 token	`https://graph.facebook.com/debug_token`
用户资料	`https://graph.facebook.com/me?fields=id,name,email`
JS SDK	`https://connect.facebook.net/en_US/sdk.js`

10. 参考（官方 + 内部）¶

来源	URL
Google GIS Overview	https://developers.google.com/identity/gsi/web/guides/overview
Google Get Client ID	https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid
Google OAuth Web Server	https://developers.google.com/identity/protocols/oauth2/web-server
Google OpenID Connect	https://developers.google.com/identity/openid-connect/openid-connect
Google OAuth Policies	https://developers.google.com/identity/protocols/oauth2/policies
Facebook Login Web	https://developers.facebook.com/docs/facebook-login/web
Facebook Manual Login Flow	https://developers.facebook.com/docs/facebook-login/guides/advanced/manual-flow
Meta Developer Policies	https://developers.facebook.com/devpolicy
非凡包网 · 登录配置	08-站点配置 §2.2

报告完成 · Bob · 2026-06-04 首版 · 2026-07-07 修订（v5：定位从「替换平台密码」校正为「新增社交入口、面向菲律宾市场拉新」）