Authentication 身份驗證

確認使用者是誰，也就是登入流程要解決的問題。

先用一句話理解

確認使用者是誰，也就是登入流程要解決的問題。

打個比方

像進大樓前刷證件。

什麼時候會遇到

有會員、後台、個人資料、訂單或權限時。

再往深一點看

Authentication（身份驗證）只回答一個問題：「你是誰？」——透過帳號密碼、OTP 簡訊、生物辨識或第三方 OAuth 登入，系統確認請求來自某個特定使用者。它不管這位使用者能做什麼，那是 Authorization（權限控管）的工作，兩者容易混淆但職責截然不同。驗證成功後，系統通常會建立一個 Session 或簽發 JWT Token，讓後續請求不必每次重新輸入密碼。自己實作 auth 容易出現 hash 弱、session 管理有漏洞、忘記 CSRF 防護等問題，現代專案普遍改用 Clerk 或 Supabase Auth 這類專門服務。

舉個例子

你用 Clerk 幫網站加會員系統：使用者在登入頁輸入 Google 帳號，Clerk 負責整段 OAuth 流程，驗證成功後回傳使用者 ID 給你的後端。你的資料庫只需要存這個 ID，Clerk 幫你管密碼、session、多因素驗證這些麻煩事。

常見誤解

- 把 Authentication 和 Authorization 當同一件事——驗證成功只代表你知道他是誰，不代表他有權限存取每一筆資料，還要額外做權限檢查。
- 只在前端隱藏登入頁或跳轉回首頁，後端 API 沒有驗證 token，攻擊者直接打 API 就能繞過登入。
- 自己用 bcrypt 手刻登入流程，卻漏掉 rate limiting、帳號鎖定或 session 到期機制，讓暴力破解有機可乘。