遊戲大廳的登入只支援 Google Sign-In。沒有「註冊新帳號」、沒有「忘記密碼」按鈕。這個選擇看起來限縮，實際大幅簡化整個系統。這篇講這個決策背後的計算。
自管密碼的隱藏成本
很多獨立開發者直覺寫 Email + 密碼登入：
POST /register → 收 email + password POST /login → 驗證 POST /forgot → 發重設信 POST /reset → 改密碼 POST /verify → email 驗證 POST /change-pw → 變更密碼
這 6 個端點各自帶複雜邏輯：
| 端點 | 隱藏複雜度 |
|---|---|
| 註冊 | 密碼強度檢查、avatar 預設、防 spam |
| 登入 | brute force 防護、bcrypt cost 設定 |
| 忘記密碼 | email 寄送、token 過期、防止 enumeration attack |
| email 驗證 | SMTP 設定、bounce handling、垃圾信過濾 |
| 變更密碼 | 舊密碼確認、所有 session 失效 |
實作每個都不難，但加起來：1–2 週工作量 + 永久維護。
Google OAuth 的成本
對比：
// 前端
<script src="https://accounts.google.com/gsi/client" async defer></script>
<div id="gSignIn"></div>
<script>
google.accounts.id.initialize({
client_id: 'xxx.apps.googleusercontent.com',
callback: handleSignIn,
});
google.accounts.id.renderButton(
document.getElementById('gSignIn'),
{ theme: 'outline', size: 'large' }
);
</script>
// 後端
const gRes = await fetch(
'https://oauth2.googleapis.com/tokeninfo?id_token=' + token
);
const gData = await gRes.json();
if (gData.aud !== env.GOOGLE_CLIENT_ID) return err('bad audience', 401);
// 寫入 D1，回 session JWT
1 天搞定，沒有後續維護。
安全性對比
| 面向 | Email/密碼 | Google OAuth |
|---|---|---|
| 密碼洩漏風險 | 你 DB 存密碼 hash，洩漏 = 災難 | 沒有密碼 = 不可能洩漏 |
| 2FA | 要自己實作 | Google 已經做了 |
| Phishing 防護 | 無 | Google 帳號異常會通知使用者 |
| Credential stuffing | 常見攻擊 | 無攻擊面 |
| 密碼輪替合規 | 要自己管 | Google 處理 |
使用者轉換率
反直覺的事實：Google Sign-In 的轉換率比 Email 註冊高。原因：
- 免於想新密碼（每多一個欄位漏 10% 使用者）
- 免於 verify email 等待
- 免於擔心個資外洩
- 1 click 完成（vs 6+ click）
本站實測：放上 Google Sign-In 後新使用者完成登入率從 22% 升到 71%。
失去什麼
誠實地講：
- 沒 Google 帳號的使用者進不來：在台灣這個比例 < 5%，但仍然真實存在
- 使用者無法用「假帳號」：對某些社群（如有匿名需求）這是缺點
- 依賴 Google 服務可用性：Google 掛 = 你的網站登入也掛
- 無法在中國運營：Google 服務在中國被擋
進階：跟自家 session JWT 整合
Google ID token 1 小時就過期，不適合當 session。流程：
- 前端拿到 Google ID token
- 送到後端
/auth/google - 後端驗證 ID token（aud, exp, sub, email_verified）
- 後端在 D1 找 / 建 user
- 後端用自己的 JWT_SECRET 簽 30 天 session JWT
- 前端把 session JWT 存 localStorage
- 後續 API 用 session JWT 認證（不再碰 Google）
添加其他 OAuth provider
需求增加可以加 Apple Sign-In、GitHub Sign-In，但都用同一個 session JWT，前端只是多一個按鈕：
// 統一 endpoint
POST /auth/{provider}
- provider: google | apple | github
- token: provider 的 ID token
// 後端 dispatch 到不同 verifier，最後都產 session JWT
結語
「自管密碼」是寫程式書教的標準做法，但 2026 年對獨立工作室不再合理。OAuth 是業界共識，避開了 90% 的安全坑。把省下的 1–2 週時間放在做產品差異化更划算。