關於 SSO 登出的那些事：Google、Microsoft、LINE 開發者必讀差異
前情提要 為何大家現在都喜歡採用 SSO? 我最近手上很多案子，都建議客戶不要自己實作帳號密碼登入，而是直接採用SSO登入。 因為，現今資安與用戶體驗的雙重考量，很多專案開發時，都會選擇整合 Google、Microsoft、LINE 這類大廠的 SSO（Single Sign-On，單一登入）機制，來取代自己儲存帳號密碼，如此可以降低很多資安風險，在面對資安稽核的時候，也省了一些什麼資料庫帳號密碼加密、金鑰保存的一堆麻煩。 而採用SSO對用戶也有一個好處，就是用戶不再需要記得很多組密碼，可以輕易實現 「一個帳號，多處通行」 。用戶在某個服務登入一次，其他整合同一身份平台的 網站/應用程式 就能直接使用，不必每次重新輸入帳密。對用戶來說方便，對開發者來說省事，對資安來說統一控管理論上也比較更安全。 但，不是每個 SSO 都能「好好登出」 某次，被客戶問到了一個問題。 客戶的用戶，使用瀏覽器登入我們的系統，但該瀏覽器會記得用戶的SSO session，因此當用戶關閉瀏覽器後，重新開啟瀏覽器登入系統時，看似需要登入，但發現即便導引到了SSO的登入畫面，卻無須輸入帳密，隨即可以登入!? 其實，SSO單一登入機制 by design 就是這樣設計的，這本來就是SSO的便利性和好處。然而，客戶卻有個疑問，如何強制讓用戶一定要用戶重新輸入帳密呢? 事實上，還真的不是每個 SSO 都能「登出」 雖然許多人都有用過 SSO，但可能很多人不知道： 不是每一個 SSO 都有支援「全域登出」的 API 或 URL 。 事實上，很多整合 SSO 的「登出」功能，本質上只是 在下一次登入時強迫重新驗證 ，並不是真的清空 IdP（身份提供者）的全域 Session。 更有趣的是： 這個所謂的「重新驗證」也不一定會要求用戶重新輸入密碼 。 有的 SSO 可以透過特定的參數在登入時直接強迫用戶輸入帳密（無視現有 Session），有的則只能「盡力要求」。最後要不要真的打密碼，還得看 SSO Provider 如何實作安全政策(例如MFA、零信任)。 就拿我在專案中最常使用的 MS, Google, LINE 三種 SSO Provider 來說，對於「登出」與「重新登入」的實作方式都不同。 Microsoft — 最直白的強制重登 https://login.m...
