GGGGoods Docs

Appearance

认证接入 ​

GGGGoods 当前通过外部认证中心完成托管登录页、authorization code 换 token、refresh token 轮换以及 userinfo 拉取。

必要环境变量 ​

text
AUTH_CENTER_LOGIN_URL=https://login.ggggoods.com/login
AUTH_CENTER_API_BASE=https://api.ggggoods.com/api
AUTH_CLIENT_ID=<oauth_client_id>
AUTH_CLIENT_SECRET=<oauth_client_secret>
AUTH_TENANT=ggggoods
AUTH_SCOPE=basic offline_access
BETTER_AUTH_SECRET=<shared_hs256_secret>

标准链路 ​

  1. Website 调用 Worker 的 /api/auth/login-url
  2. Worker 生成托管登录页 URL 并带上 state
  3. 用户登录后回到 /auth/callback
  4. Website 调用 Worker 的 /api/auth/exchange-code
  5. Worker 调外部认证中心 /oauth/token 和 /oauth/userinfo
  6. Worker 将用户 upsert 到 D1
  7. Website 保存 access token / refresh token 并继续访问 account/billing API

兼容模式 ​

如果认证中心仍返回 token 直接回跳，/auth/callback 也能接收 token 并通过 /api/auth/session 建立本地会话，但当前线上实现与标准 code flow 不同：

  1. /auth/callback?token=<jwt> 先在浏览器端按 JWT iss 请求签发方的 /api/oauth/userinfo
  2. 浏览器将 Authorization: Bearer <jwt> 和补充身份头一起发给业务 Worker 的 /api/auth/session
  3. 业务 Worker 使用 BETTER_AUTH_SECRET 本地校验 HS256 JWT
  4. Worker 用浏览器补充的身份信息或本地 D1 已有用户记录恢复 session
  5. 恢复成功后，Website 将 access token 和 session 快照写入 Pinia、cookie 与浏览器存储

兼容模式下的补充身份头为：

text
X-Auth-User-Id
X-Auth-Email
X-Auth-Email-Verified
X-Auth-Organization-Id
X-Auth-Scope

现网注意点 ​

  • legacy workers.dev 的 userinfo 不应再被业务 Worker 当成唯一依赖，优先本地 JWT 校验可以减少 404 和 522 探测噪音
  • 首次兼容登录时，JWT 若不包含 email，就需要浏览器端先拿一次 userinfo 再把身份提示带给业务 Worker
  • 后续带同一 JWT 的 API 请求可以直接由业务 Worker 基于 BETTER_AUTH_SECRET 和本地 D1 用户记录恢复会话