SPA 的 SSO 和身分驗證與授權
上課時談 OAuth，學員問到 SPA 怎麼做安全的身分驗證? 這其實是很多前端工程師都會碰到的問題，頁面是沒有後端的單頁應用程式，想要實現使用者體驗，安全性又不能妥協，那到底該怎麼做？ 先說結論：以前常見的 The OAuth 2.0 implicit grant，現在已經不是建議解法。它會把 access token 直接帶回前端（甚至出現在 URL），流程看起來簡單，但實際上會有 token 暴露、回傳路徑難以控管等問題，而且整個授權流程本身的保護也比較不足(例如授權碼被攔截後遭濫用的問題)；因此現在比較正確的做法，是用 Authorization Code Flow + PKCE (Proof Key for Code Exchange) 來完成 SPA 的登入。 如果你把這件事想成一個「前端能不能不靠傳統後端也安全登入」的題目，答案是『可以』，但前提是你要知道 PKCE 解決的是哪一段問題，也要知道它沒有解決哪些問題。 後端不是必須 一個前端App其實真的可以在沒有傳統後端的情況下，實現一個符合現代 OAuth 建議做法的登入流程。 邏輯其實很簡單，但實作的時候需要留意。 關鍵在： SPA 本來就不適合在前端保管祕密(secret) 。 傳統的 server-side web app，通常會由後端保管 client secret ，後端負責跟授權伺服器(OAuth Provider)拿 code 交換 token，前端只需要拿著後端自己發的 session 或 cookie，就可以維持身分。這種模式很合理，因為secret是放在伺服器上，不會直接暴露給使用者。 但 SPA（Single Page Application）不一樣。 因為 JavaScript 是跑在前端瀏覽器裡，使用者也拿得到前端程式碼，所以你不可能真的把 client secret 放在前端。這也是為什麼 SPA 無法走傳統的 Authorization Code Flow 的原因。 而 Authorization Code Flow + PKCE 的核心思想，就是讓這種 前端在不保管 client secret 的情況下，仍然可以比較安全地完成OAuth授權流程。 PKCE(Proof Key for Code Exchange) 的妙處 先說個比喻。 ...