SPA 的 SSO 和身分驗證與授權
上課時談到 OAuth，學員問到 SPA 怎麼做安全的身分驗證。這其實是很多前端工程師都會碰到的問題：頁面已經是單頁應用，使用者體驗想要順，安全性又不能妥協，那到底該怎麼設計？ 先說結論：以前常見的 The OAuth 2.0 implicit grant，現在已經不是建議解法。它把 access token 直接帶回前端，流程看起來簡單，實際上卻有 token 暴露、回傳路徑較難控管等問題；現在比較正確的做法，是用 Authorization Code Flow + PKCE 來完成 SPA 的登入。 如果你把這件事想成一個「前端能不能不靠傳統後端也安全登入」的題目，答案是可以，但前提是你要知道 PKCE 解決的是哪一段問題，也要知道它沒有解決哪些問題。 後端不是必須 你知道嗎，一個前端工程師其實真的可以在沒有傳統後端的情況下，實現一個符合現代 OAuth 建議做法的登入流程。我說的不是那種弄個假登入，而是 真正的 OAuth 2.0 Authorization Code Flow + PKCE 。 聽起來很狂？其實邏輯很簡單。 關鍵在於： SPA 本來就不適合在前端保管祕密 。 傳統的 server-side web app，通常會由後端保管 client secret ，後端負責跟授權伺服器交換 token，前端只需要拿到 session 或 cookie。這種模式很合理，因為祕密是放在伺服器上，不會直接暴露給使用者。 但 SPA（Single Page Application）不一樣。所有 JavaScript 都會跑在瀏覽器裡，使用者也拿得到前端程式碼，所以你不可能真的把 client secret 藏在前端。這也是為什麼 SPA 會被視為 public client。 而 Authorization Code Flow + PKCE 的核心思想，就是讓這種 public client 在不保管 client secret 的情況下，仍然可以比較安全地完成授權流程。 PKCE 的妙處 我先講個比喻。 假設你要委託朋友去銀行提錢，但你不放心他拿著提款單四處走，怕被人搶走。所以你想了個辦法：你先給銀行一個由暗號轉換而來的驗證碼，等真的要提錢時，再請朋友說出原本那個暗號。銀行拿到暗號後，重新算一次，看是不是和前面收到的驗證碼一致。 ...