SSO單點登入邏輯

天天向上518發表於2024-04-09
網站的單點登入(Single Sign-On, SSO)邏輯旨在實現使用者只需在一個地方進行一次身份驗證,就能訪問多個相互信任的應用系統或網站,無需在每個系統上單獨登入。以下是單點登入的基本邏輯流程:

1. 使用者訪問受保護資源
使用者嘗試訪問某個整合到SSO體系中的應用(如應用A)。應用A檢測到使用者未登入,於是重定向使用者到SSO系統(通常是中央認證服務,如CAS、OAuth伺服器、OpenID Connect提供者等)的登入頁面。

2. 使用者身份驗證
使用者在SSO系統的登入頁面輸入其憑據(如使用者名稱和密碼)。SSO系統透過驗證這些憑據來確認使用者的身份。這一步可能涉及與後端使用者目錄(如LDAP、AD)的互動,或者使用本地使用者資料庫進行驗證。

3. 生成和傳遞身份憑證
一旦使用者身份得到驗證,SSO系統將生成一個代表該使用者已透過驗證的身份憑證。這個憑證通常採用以下形式之一:

Session Cookie:SSO系統在使用者的瀏覽器上設定一個安全的HTTP-only cookie,用於標識已登入使用者。後續對受保護應用的請求會自動攜帶此cookie,從而實現無感知的身份驗證。

Token(如JWT):SSO系統發放一個經過簽名的JSON Web Token(JWT)或其他型別的訪問令牌給使用者瀏覽器。使用者瀏覽器在訪問其他應用時,需將此令牌附在請求頭中,供應用驗證。

4. 使用者重定向回原始應用
驗證成功後,SSO系統將使用者重定向回最初試圖訪問的應用A,並在重定向過程中(通常是查詢引數或透過POST請求)傳遞必要的身份憑證資訊(如token或一個表明身份已驗證的票據)。應用A收到這些資訊後,開始執行以下操作:

驗證憑證:應用A與SSO系統通訊(如有必要),驗證接收到的身份憑證的有效性。這可能包括檢查JWT簽名、查詢SSO系統的驗證介面,或驗證傳遞回來的票據。

建立本地會話:驗證成功後,應用A在自己的會話管理系統中為使用者建立一個新的會話,關聯使用者的賬戶資訊。此時,使用者在應用A中被視為已登入。

5. 訪問其他受保護應用
使用者在不退出的情況下訪問另一個整合到SSO體系的應用B。應用B檢測到使用者未登入,同樣重定向使用者到SSO系統。由於使用者瀏覽器上已經存在SSO系統設定的session cookie或持有有效的token:

SSO系統識別已登入狀態:SSO系統透過檢測瀏覽器上的cookie或接收到的token,識別出使用者已透過驗證,無需再次輸入憑據。

SSO系統直接重定向回應用B:基於此識別,SSO系統立即重定向使用者回應用B,並傳遞必要的身份憑證。應用B執行與應用A相同的驗證和會話建立過程,使用者無需再次登入即可訪問應用B的內容。

6. 登出操作
當使用者在任何一個應用中選擇登出時,該應用會通知SSO系統登出使用者會話。SSO系統清除使用者的session cookie或使持有的token失效,並可能觸發一個登出通知,通知所有相關應用清除各自的本地會話。這樣,使用者在所有整合SSO的系統中均被視為已登出,實現了單點登出(Single Logout, SLO)。

總結來說,單點登入邏輯的核心在於利用一個統一的認證中心來集中處理使用者身份驗證,透過安全的憑證傳遞機制(如cookies或tokens)以及重定向流程,使得使用者能夠在多個互信應用之間無縫切換,無需多次登入。
1:有3個應用 如:A淘寶,B小米之家,C華為, 第3方權威機構開發的 D: sso體系 (已經整合了A,B,C應用)

2:使用者想要在A,B,C 3個系統之間隨意登入,首先得有A,B,C,D 對應的賬號密碼,就是有認證註冊過
 一個使用者想登入A系統,應該是點選A系統的SSO標識(才會採用該方案,去D sso體系,輸入賬號和密碼)
3:成功登入D認證系統後 會帶上對應的token,和 D sso登入中心自己的使用者id 如10011, 在A系統中查詢是否有繫結使用者id 10011,如果有就查到對應的A系統使用者賬號密碼生成 A應用的登入流程,
如果沒有繫結就要輸入 A系統的 賬號密碼(賬號密碼或者手機或者郵箱等方式,看該應用自己的登入邏輯)和id 10011來繫結
4:繫結成功既可以開啟A應用了,其他B,C應用一樣的邏輯處理

相關文章