關於 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.microsoftonline.com/common/oauth2/v2.0/authorize
  ?client_id=...
  &response_type=code
  &redirect_uri=...
  &scope=openid profile email
  &state=...
  &prompt=login
  • prompt=login 會直接要求重新輸入憑證，SSO 再見。

Google — 溫和又含蓄的提醒

https://accounts.google.com/o/oauth2/v2/auth
  ?client_id=...
  &response_type=code
  &redirect_uri=...
  &scope=openid email profile
  &state=...
  &max_age=0
  &prompt=select_account
  • max_age=0：要求重新驗證
  • prompt=select_account：至少會出現帳號選擇器，但不一定要密碼
  • Google 不支援 prompt=login

LINE — 有點任性的選擇性重登

https://access.line.me/oauth2/v2.1/authorize
  ?client_id=...
  &response_type=code
  &redirect_uri=...
  &scope=openid profile
  &state=...
  &prompt=login
  &max_age=0
  &disable_auto_login=true
  • prompt=login：要求顯示登入畫面
  • max_age=0：觸發重新驗證檢查
  • disable_auto_login=true：避免 LINE 自動帶你進去
  • 但如果 LINE App/Web session 還在，可能依舊秒過

小小總結

  • 如果你的場景一定要使用者重新輸入帳密，Microsoft 是最好控制的。
  • Google/LINE 只能盡量逼近結果，但無法百分百保證，需要配合清除 IdP cookie 或瀏覽器的無痕模式來達成。(所以，如果用戶要保證你的帳號不殘留，要求用戶使用無痕視窗是最安全的)
  • 登出策略要根據安全需求、用戶體驗與 IdP 限制來決定，不要假設「重新登入 == 一定會要求用戶重新輸入」。

關於登入策略

假設你的應用程式採用了 SSO 登入，大部分應用程式實作的登出功能，其實只是清除應用程式本身的 token/session，但不影響 IdP 的 SSO 狀態。(這也是用戶重新開啟瀏覽器，進行登入時無須輸入帳密的原因)

如果要清除IdP 的瀏覽器 Session，可使用 /logout（Google/Microsoft 可做到，但 LINE 沒有），不然就是用戶必須手動清除瀏覽器 cookies。而如果要 強制重新驗證，則可以透過 redirect url 參數（如 prompt=login、max_age）讓用戶在下一次登入SSO十，一定要經過互動驗證(但並不代表 100%會重新輸入密碼)。

開發時，你必須確認你的用戶所要的登出，究竟是哪一種登出，並且跟用戶做好說明。免得用戶「以為自己已經登出」但其實重開瀏覽器後，還是秒登入。

提醒 👉 別假設「重新登入 == 打密碼」

Google / LINE 可能直接讓用戶選帳號或用 Passkey/Face ID 通過，完全沒有打密碼的機會。如果你的需求是高資安情境（如銀行交易、重大設定變更），請結合清除全域 cookie 或乾脆引導用戶使用無痕模式。

另外，「登出」和「切換帳號」是不同的邏輯，很多時候，使用者的「登出」，其實是想換另一個帳號登入。對 Google / LINE 來說，prompt=select_account 是比較柔和的做法，可以讓用戶切帳號而不完全破壞 SSO 登入狀態。(但要注意這等於同一個瀏覽器登入了多個帳號，絕對不適合讓用戶在公用電腦使用)

以上，是SSO在登出上的一些實作策略，希望對開發應用程式的大家有幫助。

底下是展示 repo:
https://github.com/isdaviddong/sso-relogin-demo

留言

張貼留言

這個網誌中的熱門文章

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

原來使用 .net 寫個 MCP Server 如此簡單

作者： -
圖片
MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...
Read more »

C# 格式化(formatter)在 VS Code 中的選擇

作者： -
圖片
程式碼的世界裡，有一個古老的爭論： 大括號 { 到底該放在同一行，還是獨立成一行？ 這不只是排版問題，有時甚至會演變成團隊會議上的「宗教戰爭」。而我自己也有喜歡的 indent style ，如果看到團隊中其他人的寫法和我不同，雖不至於惱怒，但總覺得有些彆扭。有一種衝動很想把它全部改成自己習慣的方式。 你大概可以想像，當有一天，我發現 VS Code 升級到新版之後，排版和對齊方式竟然變成和我喜歡的不同，那時候我有多麼的震驚，一整天都想要把它給改回來。 怎麼做? 今天我們就來談談，如何在 VS Code 裡改設定，讓 { 的排版聽話。 兩種常見風格 先來看看範例： 1. K&R （大括號跟在同一行） public class HelloWorld { public void SayHello ( ) { if ( true ) { Console . WriteLine ( "Hello, world!" ) ; } } } 2. Allman Style（大括號獨立一行） public class HelloWorld { public void SayHello ( ) { if ( true ) { Console . WriteLine ( "Hello, world!" ) ; } } } 先問問，你喜歡哪一種? 各自的優缺點 同一行風格 (K&R) ✔ 節省垂直空間，檔案比較短。 ✔ 很多 C# 官方範例和文件都是這種格式。 ✘ 有人覺得程式「擠在一起」，閱讀時容易忽略最末端的 { 。 獨立一行風格 (Allman) ✔ 大括號醒目，結構一眼就能看出來。 ✔ 不容易漏掉對應的 { 與 } 。 ✘ 程式會「莫名變長」，多佔好幾行。 👉 簡單說：前者像極簡主義，後者像穿寬鬆衣服，空間感十足。 你是哪一派呢？ 在 VS Code 裡如何調整？ 方法一： .editorconfig （推薦） 在專案或解決方案根目錄新增 .editorconfig 檔案： root = true [*...
Read more »

Junior Developers 在 Vibe Coding 時的問題與挑戰

作者： -
圖片
最近有個發生在我們專案上的真實案例。 一位初階開發人員用 AI 一口氣生出 前端註冊表單 以及 後端驗證與寫入資料庫 的程式碼。建置沒錯、可以運行、AI 自我檢查後也說了聲沒問題，但是一跑， 前端的資料就是進不到後端模型 ，驗證當然也就永遠失敗。 這位 Junior Developer 卡在這邊三小時(生成這段程式碼的時間其實只有5分鐘)，直到下班前，一票老傢伙看不下去，在旁邊盯著把前後端程式碼一一對起來後才發現，問題居然只需要改一個字母而已。 現場重現：前端 AJAX 送這個 劇情其實很簡單，前端把使用者輸入後的資料，包裹成類似底下這樣的 JSON，透過 AJAX 丟到後端 Controller： { "UserName" : "Rick" , "Email" : "rick@example.com" , "Password" : "P@ssw0rd!" , "PhoneNumber" : "0987123456" } 產出上面的這段 JSON 的程式碼是 AI 寫的。 而接著 ASP.NET Core 的 Controller 大概長底下這樣： [ ApiController ] [ Route ( "api/[controller]" ) ] public class AuthController : ControllerBase { [ HttpPost ( "register" ) ] public IActionResult Register ( [ FromBody ] RegisterRequest input ) { // input 的屬性全是 null -> 驗證失敗 if ( input is null || string . IsNullOrWhiteSpace ( input . username ) ) return BadRequest ( "payload invalid." ) ; /...
Read more »