如何設計一個登入系統

「設計一個登入系統」是身份驗證系列裡最典型的系統設計題。

它看起來很簡單：

text

使用者輸入帳號密碼
後端驗證
登入成功

但真的要設計完整，會牽涉到：

註冊。
信箱驗證。
密碼儲存。
登入失敗限制。
Session / Cookie。
JWT / Token。
Remember me。
MFA。
第三方登入。
登出與多裝置管理。
高風險操作重新驗證。
安全通知。
稽核紀錄。
風控與告警。

所以這題的重點不是「會不會寫 login API」。

真正要考的是：

text

你能不能把身份驗證當成一個長期運作的安全系統來設計。

一、一句話回答

如果面試官問：

如何設計一個登入系統？

可以先回答：

我會先拆需求：使用者如何註冊與驗證身份、登入後如何維持狀態、憑證和 session 如何安全保存、失敗登入與異常行為如何風控、敏感操作是否需要 MFA 或重新驗證，以及所有安全事件如何稽核。典型設計是：密碼用 Argon2id 或 bcrypt 加 salt 儲存；登入成功後建立 server-side session，透過 HttpOnly、Secure、SameSite cookie 保存 session id；登入失敗要做 rate limit、credential stuffing 偵測與安全通知；高風險操作使用 MFA 或 step-up authentication；登出要撤銷 session 或 refresh token；所有登入、登出、失敗、MFA、敏感操作都要記錄 audit log。若是前後端分離或 App 場景，也可以用 access token + refresh token，但要處理短效、旋轉、撤銷與外洩風險。

短一點可以說：

text

登入系統不是一支 API，
而是身份、憑證、Session、風控、稽核和使用者恢復流程的組合。

二、先問需求

系統設計題不要一開始就說：

text

我用 JWT。

應該先問需求。

問題	為什麼重要
是一般網站、後台、金融、醫療，還是政府服務？	風險等級不同
使用者量級多大？	影響 session store、rate limit、資料庫設計
是否支援第三方登入？	需要 OAuth / OIDC / account linking
是否支援多裝置登入？	需要 session list 與撤銷
是否需要 MFA？	影響登入流程和恢復流程
是否有敏感操作？	需要 step-up authentication
是否有 App / SPA / SSR？	影響 token / cookie 保存方式
是否需要企業 SSO？	可能需要 SAML / OIDC
是否有法規與稽核要求？	影響 audit log、保存時間與告警

面試回答可以先說：

text

我先以一般 Web 應用為主，支援帳密登入、信箱驗證、多裝置 session、MFA 和基本風控；
如果是金融或醫療場景，我會再提高 MFA、重新驗證、稽核和簽章要求。

這樣範圍就清楚了。

三、系統邊界

一個登入系統至少會有這些模組：

核心分工：

模組	責任
Auth Service	註冊、登入、登出、密碼驗證、session 建立
User DB	使用者、密碼 hash、帳號狀態、MFA 設定
Session Store	server-side session、裝置列表、撤銷
Token Store	refresh token、旋轉、撤銷
Risk Engine	rate limit、異常登入、風險評分
MFA Service	TOTP、Passkey、Backup codes、OTP
Audit Log	安全事件與敏感操作紀錄
Notification	信箱驗證、安全通知、告警
Auth Middleware	每個 API 的身份與權限檢查

小系統可以把這些放在同一個服務裡。

大系統才拆成多個服務。

重點不是一開始就微服務，而是責任邊界要清楚。

四、資料模型

登入系統常見資料表：

sql

create table users (
  id uuid primary key,
  email text unique,
  phone text unique,
  password_hash text,
  status text not null,
  email_verified_at timestamp,
  phone_verified_at timestamp,
  created_at timestamp not null,
  updated_at timestamp not null
);

create table sessions (
  id uuid primary key,
  user_id uuid not null references users(id),
  session_hash text not null unique,
  device_name text,
  ip inet,
  user_agent text,
  last_seen_at timestamp not null,
  authenticated_at timestamp not null,
  expires_at timestamp not null,
  revoked_at timestamp
);

create table auth_events (
  id uuid primary key,
  user_id uuid,
  event_type text not null,
  result text not null,
  ip inet,
  user_agent text,
  risk_score integer,
  reason text,
  created_at timestamp not null
);

create table mfa_factors (
  id uuid primary key,
  user_id uuid not null references users(id),
  factor_type text not null,
  secret_hash text,
  public_key text,
  enabled_at timestamp,
  revoked_at timestamp
);

注意幾點：

不存明文密碼。
session id 不要明文存資料庫，建議存 hash。
audit log 不要混在一般 application log 裡。
MFA secret 要加密或用安全方式保護。
敏感欄位要做最小化保存。

五、註冊流程

註冊不是只新增一筆 user。

典型流程：

設計重點：

密碼在前端只做基本 UX 檢查，真正檢查在後端。
verification token 要短效、隨機、單次使用。
不要在錯誤訊息透露 email 是否已註冊太多細節。
註冊、驗證、重寄都要 rate limit。
信箱驗證不等於身份驗證，只能證明使用者控制該信箱。

如果支援手機驗證，OTP 也要有：

短效。
重試限制。
重寄限制。
使用後失效。
防暴力猜測。

六、密碼儲存

密碼儲存是登入系統底線。

正確方向：

text

password -> slow hash -> hash stored

常見選擇：

方法	說明
Argon2id	現代密碼 hash 推薦選擇之一，可調 memory cost
bcrypt	實務常見，成熟穩定
PBKDF2	可用，但參數要足夠

不要使用：

text

MD5
SHA1
SHA256(password)
可逆加密密碼

密碼儲存可以有：

salt：每個密碼不同，通常 hash 函式會處理。
pepper：系統級秘密，放在 KMS 或環境秘密管理，不放 DB。
hash version：方便未來升級 hash 演算法。

登入時如果發現舊 hash，可以做 lazy rehash：

text

使用者登入成功
-> 發現 hash 參數過舊
-> 用新參數重新 hash
-> 更新資料庫

七、登入流程

典型帳密登入：

登入成功後：

建立 session。
記錄登入事件。
更新 last_login_at。
風險高時發通知。
需要 MFA 時先不要建立完整 session，或建立 pending session。

登入失敗後：

記錄失敗事件。
增加 rate limit 計數。
不透露帳號是否存在。
必要時要求 captcha 或 MFA。

錯誤訊息應該像：

text

帳號或密碼錯誤。

不要說：

text

此 email 未註冊。

或：

text

密碼錯誤，但帳號存在。

一般 Web 應用最穩的預設是：

text

server-side session + HttpOnly Secure SameSite cookie

Cookie 範例：

http

Set-Cookie: __Host-session=<opaque-random-id>; Path=/; HttpOnly; Secure; SameSite=Lax

設計重點：

設計	原因
session id 隨機且高 entropy	防猜測
HttpOnly	降低 XSS 直接偷 cookie
Secure	只透過 HTTPS 傳送
SameSite	降低 CSRF 風險
Path=/	明確 cookie 範圍
不設定 Domain 搭配 `__Host-`	降低子網域偽造風險
server-side revoke	能登出和踢裝置

OWASP Session Management Cheat Sheet 也強調 session id 要有足夠隨機性，並使用 cookie attributes 保護 session id。

Session store 裡不要放太多敏感資料。

比較好的做法是：

text

cookie 只放 session id
server 查 session
server 再查 user 和權限

九、 JWT 和 Token 什麼時候用

JWT 不是不能用，但不應該 reflexively 使用。

適合使用 token 的場景：

Mobile App。
第三方 API。
微服務間 delegation。
OAuth / OIDC。
stateless access token + refresh token 架構。

但要處理：

access token 短效。
refresh token 長效但可撤銷。
refresh token rotation。
refresh token reuse detection。
token audience / issuer / scope。
金鑰輪替。
登出與撤銷。

常見設計：

text

access token：5 到 15 分鐘
refresh token：數天到數週，依風險和產品而定
refresh token 每次使用都旋轉
偵測舊 refresh token 重放就撤銷整個 token family

如果是純 Web 前端：

text

不要把長效 refresh token 放 localStorage。

因為 XSS 一旦發生，localStorage token 很容易被讀走。

Web 場景通常更推薦：

text

HttpOnly cookie + server-side session

或：

text

HttpOnly cookie 保存 refresh token，access token 放 memory。

但細節要看 SSR、跨域、API gateway、mobile app 等需求。

十、 MFA 設計

MFA 不只是登入時輸入一組碼。

需要設計：

何時要求 MFA。
支援哪些因素。
如何啟用。
如何停用。
如何恢復帳號。
backup codes。
裝置遺失流程。
高風險操作重新驗證。

常見因素：

因素	特性
TOTP	成熟、便宜，但可能被釣魚
SMS OTP	易用，但 SIM swap 與攔截風險較高
Email OTP	方便，但依賴 email 帳號安全
Passkey / WebAuthn	抗釣魚能力較強
Backup codes	帳號恢復用，需一次性使用

啟用 MFA 流程：

text

使用者已登入
-> 重新驗證
-> 建立 MFA secret / passkey registration
-> 使用者完成一次驗證
-> 才正式啟用
-> 產生 backup codes
-> 記錄 audit log
-> 發送安全通知

停用 MFA 比啟用更敏感。

停用時應該：

要求重新驗證。
要求現有 MFA 或 backup code。
記錄 audit log。
發安全通知。
必要時撤銷其他 session。

十一、 Rate Limit 與防暴力破解

登入系統一定要防：

暴力破解。
credential stuffing。
password spraying。
OTP 猜測。
verification token 猜測。

Rate limit 不能只有一種 key。

可以組合：

維度	目的
IP	擋單點攻擊
account	擋針對某帳號猜密碼
IP + account	擋特定來源打特定帳號
device fingerprint	輔助判斷
ASN / country	風險評分
credential pair hash	偵測 credential stuffing

錯誤處理：

text

前幾次失敗：正常錯誤訊息
多次失敗：延遲、captcha、MFA、暫時限制
大量分散式攻擊：風控規則、WAF、告警

不要輕易永久鎖帳號。

因為攻擊者可以用登入失敗造成使用者帳號被鎖，形成 denial of service。

比較好的方式是：

暫時限制。
要求額外驗證。
只限制高風險來源。
通知使用者。

十二、登出與多裝置管理

登入系統不是只有 login，還要有 logout。

基本功能：

登出目前裝置。
登出所有裝置。
查看已登入裝置。
撤銷單一 session。
修改密碼後撤銷其他 session。
停用帳號後撤銷所有 session。

登出目前裝置：

text

server revoke session
client expire cookie
record audit log

登出所有裝置：

text

revoke all sessions for user
revoke refresh tokens
rotate security stamp / token version
record audit log
notify user

多裝置列表可以顯示：

裝置名稱。
大略地點。
IP。
最近活動時間。
是否目前裝置。

不要顯示太敏感的原始資訊。

十三、高風險操作重新驗證

登入後不是所有操作都應該直接允許。

敏感操作應該要求 recent auth 或 step-up authentication。

例如：

修改密碼。
修改 Email / 手機。
停用 MFA。
新增 Passkey。
查看 API key。
匯出大量資料。
新增收款帳號。
管理員刪除資料。

設計：

text

敏感 API 檢查 session
-> 檢查權限
-> 檢查 recent auth / step-up grant
-> 不足則回 reauth_required
-> 使用者完成 MFA / Passkey
-> 發短效 step-up grant
-> 執行敏感操作
-> 記錄 audit log

step-up grant 要：

短效。
單用途。
綁定 user。
綁定 session。
綁定 purpose。
可單次使用。

這一段可以直接銜接前一篇。

十四、第三方登入與帳號綁定

如果支援 Google、LINE、GitHub 登入，要分清楚：

text

OAuth 是授權協議。
OIDC 才提供身份層。
第三方登入通常應使用 OIDC id token 或 userinfo 取得身份資料。

資料表概念：

sql

create table external_identities (
  id uuid primary key,
  user_id uuid not null references users(id),
  provider text not null,
  provider_subject text not null,
  email text,
  email_verified boolean,
  linked_at timestamp not null,
  unique (provider, provider_subject)
);

帳號綁定要處理：

同 email 但不同 provider。
provider email 未驗證。
使用者已存在本地帳密。
解除綁定後是否還有其他登入方式。
第三方登入被移除或失效。

危險做法：

text

只要第三方回傳 email 相同，就自動合併帳號。

更好的做法是：

text

依 provider subject 建立唯一身份，
email 只能作為輔助資訊，
高風險合併要重新驗證或讓使用者明確確認。

十五、權限不是登入

登入成功只代表：

text

你是誰。

不代表：

text

你能做什麼。

每個業務 API 都還要做 authorization。

例如：

async function getInvoice(req: Request) {
  const session = await requireSession(req)
  const invoice = await invoices.find(req.params.id)

  if (invoice.userId !== session.userId) {
    throw new ForbiddenError()
  }

  return invoice
}

後台系統也要檢查：

role。
permission。
tenant。
resource ownership。
data scope。
operation risk。

不要在前端藏按鈕就以為有權限控管。

十六、 Audit Log 與安全通知

身份系統一定要能追。

至少記錄：

註冊。
登入成功。
登入失敗。
登出。
密碼修改。
忘記密碼。
Email / 手機變更。
MFA 啟用 / 停用。
Backup codes 產生。
Passkey 新增 / 刪除。
第三方登入綁定 / 解除。
高風險操作重新驗證。
管理員權限變更。

Audit log 欄位：

sql

create table auth_audit_logs (
  id uuid primary key,
  user_id uuid,
  actor_user_id uuid,
  event_type text not null,
  result text not null,
  ip inet,
  user_agent text,
  request_id text,
  risk_score integer,
  metadata jsonb,
  created_at timestamp not null
);

安全通知：

新裝置登入。
密碼修改。
MFA 停用。
新增 Passkey。
新增收款帳號。
帳號恢復完成。

通知要附上：

發生時間。
大略地點。
裝置資訊。
如果不是本人該怎麼處理。

但不要在通知裡放完整敏感資料。

十七、風控與異常偵測

登入系統不能只看密碼對不對。

也要看：

IP 是否異常。
地理位置是否突然變化。
裝置是否新裝置。
是否短時間大量失敗。
是否從資料中心 IP 來。
是否命中外洩密碼。
是否有 credential stuffing pattern。
是否剛完成帳號恢復。

風險分數可以影響：

風險	處理
低	正常登入
中	發安全通知
高	要求 MFA
很高	暫時拒絕、要求帳號恢復、人工審核

這就是 risk-based authentication 的核心。

但風控要注意誤傷。

如果太敏感，使用者會一直被擋。

如果太寬鬆，攻擊者會容易通過。

十八、可用性與恢復流程

安全系統一定會遇到：

忘記密碼。
手機遺失。
MFA 裝置遺失。
Email 被盜。
第三方登入失效。
使用者換手機。

所以要設計恢復流程。

忘記密碼：

reset token 短效。
單次使用。
存 hash。
成功後撤銷舊 session。
發通知。

MFA 恢復：

backup codes。
已登入裝置重新驗證。
客服審核。
高風險冷卻期。

恢復流程通常是身份系統最脆弱的地方。

不要讓攻擊者繞過 MFA，透過客服或 email 直接接管帳號。

十九、 API 設計範例

常見 endpoint：

text

POST /auth/register
POST /auth/verify-email
POST /auth/login
POST /auth/mfa/verify
POST /auth/logout
POST /auth/logout-all
GET  /auth/sessions
DELETE /auth/sessions/:id
POST /auth/password/forgot
POST /auth/password/reset
POST /auth/password/change
POST /auth/reauth
GET  /auth/me
POST /auth/mfa/totp/setup
POST /auth/mfa/totp/enable
POST /auth/mfa/disable
POST /auth/passkeys/register/options
POST /auth/passkeys/register/verify
DELETE /auth/passkeys/:id

中介層：

async function requireSession(req: Request) {
  const sessionId = readSessionCookie(req)
  if (!sessionId) throw new UnauthorizedError()

  const session = await sessions.findByToken(sessionId)
  if (!session || session.revokedAt || session.expiresAt < new Date()) {
    throw new UnauthorizedError()
  }

  await sessions.touch(session.id)
  return session
}

async function requireStepUp(req: Request, purpose: string) {
  const session = await requireSession(req)
  const grant = await stepUpGrants.verify({
    token: req.headers['x-step-up-token'],
    userId: session.userId,
    sessionId: session.id,
    purpose
  })

  if (!grant) throw new ReauthRequiredError(purpose)
  return { session, grant }
}

二十、常見架構選型

1. 傳統 Web

建議：

text

server-side session + HttpOnly Secure SameSite cookie

優點：

可撤銷。
實作清楚。
適合 SSR / MVC / 一般網站。

2. SPA + API

可選：

text

HttpOnly cookie session

或：

text

短效 access token in memory + refresh token in HttpOnly cookie

注意：

CORS。
CSRF。
XSS。
token refresh。
SSR hydration。

3. Mobile App

常見：

text

access token + refresh token

refresh token 要放在安全儲存，例如 Keychain / Keystore。

要做：

refresh token rotation。
裝置綁定。
遠端撤銷。
生物辨識只是本機解鎖，不一定等於伺服器 MFA。

4. 微服務

可以：

text

Auth service 驗證身份
API gateway 驗證 token/session
下游服務接收已驗證 user context

但要避免：

每個服務自己亂實作 auth。
JWT scope 不檢查。
token audience 混用。
內網服務完全信任 header。

二十一、安全檢查清單

上線前至少檢查：

密碼是否使用 Argon2id / bcrypt 等慢 hash。
是否有 rate limit。
登入錯誤是否不洩漏帳號存在性。
session id 是否足夠隨機。
cookie 是否有 HttpOnly、Secure、SameSite。
HTTPS 是否強制。
登入成功是否旋轉 session。
登出是否真的撤銷 server-side session。
修改密碼是否撤銷其他 session。
忘記密碼 token 是否短效、單次、存 hash。
MFA 是否有 backup codes。
停用 MFA 是否重新驗證。
高風險操作是否 step-up。
第三方登入是否用 provider subject 綁定。
是否記錄 auth audit log。
是否有安全通知。
是否有監控與告警。
是否有帳號恢復流程。

二十二、常見錯誤

1. 一開始就選 JWT

錯誤：

text

登入系統就用 JWT。

正確：

text

先看場景。一般 Web 可能 server-side session 更簡單可控；JWT 要處理撤銷、輪替、外洩與有效期。

2. 把密碼加密存在資料庫

錯誤：

text

password = AES.encrypt(rawPassword)

正確：

text

password_hash = Argon2id / bcrypt(rawPassword + salt)

3. 只做登入，不做登出與撤銷

錯誤：

text

前端刪 token 就算登出。

正確：

text

server-side session / refresh token 也要撤銷。

4. MFA 沒有恢復流程

錯誤：

text

使用者手機掉了就只能找客服手動關 MFA。

正確：

text

backup codes、恢復流程、重新驗證、冷卻期和 audit log 都要設計。

5. 忘記密碼變成帳號接管入口

錯誤：

text

reset token 很長效，可以重複用，成功後舊 session 還在。

正確：

text

短效、單次、存 hash、成功後撤銷 session 並通知。

6. 權限只在前端判斷

錯誤：

text

沒有權限就不顯示按鈕。

正確：

text

每個後端 API 都要檢查身份、權限和資料範圍。

二十三、面試追問題庫

Q1：登入系統要包含哪些模組？

至少包含註冊、信箱或手機驗證、密碼儲存、登入、session/token 管理、登出、多裝置管理、MFA、忘記密碼、rate limit、風控、audit log 和安全通知。

Q2：Session 和 JWT 怎麼選？

一般 Web 應用常用 server-side session + HttpOnly cookie，因為可撤銷、易控管。JWT 適合 mobile、API、OAuth/OIDC 或跨服務場景，但要處理短效、refresh token、撤銷、輪替和外洩風險。

使用隨機 session id，cookie 設 HttpOnly、Secure、SameSite=Lax/Strict，建議使用 __Host- prefix，不在 cookie 存敏感資料，server-side 保存 session 並支援撤銷。

Q4：如何防暴力破解？

用 IP、account、IP+account、device 等多維度 rate limit，偵測 credential stuffing 和 password spraying，必要時要求 captcha、MFA、延遲或暫時限制，但避免讓攻擊者用失敗登入永久鎖別人的帳號。

Q5：忘記密碼怎麼設計？

產生短效、單次使用、高隨機 reset token，資料庫保存 token hash，寄送到已驗證信箱；重設成功後撤銷舊 session / refresh token，記錄 audit log 並發安全通知。

Q6：MFA 要注意什麼？

啟用 MFA 要先完成一次驗證才生效，產生 backup codes；停用 MFA 是高風險操作，必須重新驗證，最好要求現有 MFA，並記錄 audit log 和發通知。

Q7：如何設計多裝置登出？

每個 session 或 refresh token 都有獨立記錄。登出目前裝置只撤銷該 session；登出全部裝置撤銷該 user 的所有 session / refresh token，並更新安全版本與 audit log。

Q8：登入系統最容易忽略什麼？

忘記密碼、MFA 恢復、session 撤銷、rate limit、audit log、高風險操作重新驗證和安全通知。這些通常比 login API 本身更容易出安全事故。

二十四、實作題

題目一：設計帳密登入 API

好的答案：

後端收到 email/password。
做輸入驗證與 rate limit。
查 user。
使用慢 hash 驗證密碼。
檢查帳號狀態。
評估風險。
若需要 MFA，回傳 mfa_required。
驗證成功後建立 session。
設定安全 cookie。
記錄 auth event。

題目二：設計忘記密碼

好的答案：

不透露 email 是否存在。
token 高隨機。
token hash 存 DB。
token 短效。
單次使用。
重設成功後撤銷舊 session。
發安全通知。
記錄 audit log。

題目三：設計登入系統資料表

至少包含：

users。
sessions。
refresh_tokens。
password_reset_tokens。
email_verification_tokens。
mfa_factors。
backup_codes。
external_identities。
auth_audit_logs。

題目四：設計高風險操作

例如停用 MFA：

require session。
require permission。
require recent strong auth。
require existing MFA 或 backup code。
disable MFA。
revoke backup codes。
rotate session。
audit log。
security notification。

二十五、資深視角

1. 登入系統的核心是生命週期

初階答案常只講：

text

使用者登入，後端回 token。

資深答案會講生命週期：

text

註冊 -> 驗證 -> 登入 -> 維持 session -> 提升驗證 -> 登出 -> 撤銷 -> 恢復 -> 稽核

登入只是其中一段。

2. 安全不是單點功能，是互相補位

密碼 hash、防暴力破解、MFA、session cookie、CSRF、防 XSS、audit log、通知、風控不是互相替代。

它們是在不同攻擊路徑上補位。

例如：

text

HttpOnly cookie 降低 token 被 JS 讀走的風險，
但不能防止所有 XSS 下的操作冒用。

所以還要有 CSRF、防 XSS、step-up、audit log。

3. 可撤銷性很重要

身份系統一定要問：

text

如果 token 外洩，我怎麼讓它失效？
如果裝置遺失，我怎麼踢掉它？
如果 MFA 被停用，我怎麼通知使用者？
如果帳號被接管，我怎麼恢復？

這些是「能不能營運」的差別。

4. 面試時要主動談 trade-off

例如：

text

Server-side session 易撤銷，但需要 session store。
JWT 易跨服務傳遞，但撤銷和外洩處理較麻煩。
SMS OTP 易用，但安全性不如 Passkey。
頻繁重新驗證安全但打擾使用者，所以要用風險分級。

能講 trade-off，答案就會立體很多。

總結

面向	設計重點
註冊	email / phone 驗證、token 短效單次
密碼	Argon2id / bcrypt、salt、pepper、hash version
登入	rate limit、風險評估、MFA、auth event
Session	server-side session、HttpOnly / Secure / SameSite cookie
Token	短效 access token、refresh token rotation、撤銷
MFA	TOTP、Passkey、backup codes、恢復流程
登出	撤銷 session / refresh token，多裝置管理
風控	credential stuffing、異常登入、risk-based auth
高風險操作	step-up authentication、短效 grant
稽核	auth events、audit log、安全通知

一句完整的面試回答可以是：

我會把登入系統拆成身份資料、憑證驗證、session/token 管理、風控、MFA、帳號恢復、稽核和通知幾個部分。使用者註冊後要做信箱或手機驗證；密碼用 Argon2id 或 bcrypt 加 salt 儲存；登入時做 rate limit、密碼驗證、帳號狀態檢查和風險評估，必要時要求 MFA；Web 場景預設使用 server-side session 搭配 HttpOnly、Secure、SameSite cookie；App 或 API 場景可用短效 access token 加 refresh token rotation。登出要撤銷 session 或 refresh token，多裝置要能查看和踢除；修改密碼、停用 MFA、匯出資料等敏感操作要做 step-up authentication；所有登入、失敗、登出、MFA、重設密碼和敏感操作都要記錄 audit log 並在必要時發安全通知。

如何設計一個登入系統 ​

一、 一句話回答 ​

二、 先問需求 ​

三、 系統邊界 ​

四、 資料模型 ​

五、 註冊流程 ​

六、 密碼儲存 ​

七、 登入流程 ​

八、 Session Cookie 設計 ​

九、 JWT 和 Token 什麼時候用 ​

十、 MFA 設計 ​

十一、 Rate Limit 與防暴力破解 ​

十二、 登出與多裝置管理 ​

十三、 高風險操作重新驗證 ​

十四、 第三方登入與帳號綁定 ​

十五、 權限不是登入 ​

十六、 Audit Log 與安全通知 ​

十七、 風控與異常偵測 ​

十八、 可用性與恢復流程 ​

十九、 API 設計範例 ​

二十、 常見架構選型 ​

1. 傳統 Web ​

2. SPA + API ​

3. Mobile App ​

4. 微服務 ​

二十一、 安全檢查清單 ​

二十二、 常見錯誤 ​

1. 一開始就選 JWT ​

2. 把密碼加密存在資料庫 ​

3. 只做登入，不做登出與撤銷 ​

4. MFA 沒有恢復流程 ​

5. 忘記密碼變成帳號接管入口 ​

6. 權限只在前端判斷 ​

二十三、 面試追問題庫 ​

Q1：登入系統要包含哪些模組？ ​

Q2：Session 和 JWT 怎麼選？ ​

Q3：登入成功後 cookie 要怎麼設？ ​

Q4：如何防暴力破解？ ​

Q5：忘記密碼怎麼設計？ ​

Q6：MFA 要注意什麼？ ​

Q7：如何設計多裝置登出？ ​

Q8：登入系統最容易忽略什麼？ ​

二十四、 實作題 ​

題目一：設計帳密登入 API ​

題目二：設計忘記密碼 ​

題目三：設計登入系統資料表 ​

題目四：設計高風險操作 ​

二十五、 資深視角 ​

1. 登入系統的核心是生命週期 ​

2. 安全不是單點功能，是互相補位 ​

3. 可撤銷性很重要 ​

4. 面試時要主動談 trade-off ​

總結 ​

延伸閱讀 ​

如何設計一個登入系統

一、一句話回答

二、先問需求

三、系統邊界

四、資料模型

五、註冊流程

六、密碼儲存

七、登入流程

八、 Session Cookie 設計

九、 JWT 和 Token 什麼時候用

十、 MFA 設計

十一、 Rate Limit 與防暴力破解

十二、登出與多裝置管理

十三、高風險操作重新驗證

十四、第三方登入與帳號綁定

十五、權限不是登入

十六、 Audit Log 與安全通知

十七、風控與異常偵測

十八、可用性與恢復流程

十九、 API 設計範例

二十、常見架構選型

1. 傳統 Web

2. SPA + API

3. Mobile App

4. 微服務

二十一、安全檢查清單

二十二、常見錯誤

1. 一開始就選 JWT

2. 把密碼加密存在資料庫

3. 只做登入，不做登出與撤銷

4. MFA 沒有恢復流程

5. 忘記密碼變成帳號接管入口

6. 權限只在前端判斷

二十三、面試追問題庫

Q1：登入系統要包含哪些模組？

Q2：Session 和 JWT 怎麼選？

Q3：登入成功後 cookie 要怎麼設？

Q4：如何防暴力破解？

Q5：忘記密碼怎麼設計？

Q6：MFA 要注意什麼？

Q7：如何設計多裝置登出？

Q8：登入系統最容易忽略什麼？

二十四、實作題

題目一：設計帳密登入 API

題目二：設計忘記密碼

題目三：設計登入系統資料表

題目四：設計高風險操作

二十五、資深視角

1. 登入系統的核心是生命週期

2. 安全不是單點功能，是互相補位

3. 可撤銷性很重要

4. 面試時要主動談 trade-off

總結

延伸閱讀