SSO-單點統一登陸系統的設計與實現

本文主要基於web類應用展開討論,提供的是一種通用機制和方法,因此不論何種技術棧均可進行相應的具體實現。web

實現目標

能夠在相同或跨域環境下完成各應用的統一登陸/註銷json

方案原理

本質上是採用了web應用的會話技術和機制,因此才使得此方案的可操做性和通用性乃至規範性上有了自然的優點。會話追蹤主要有Session、Cookie兩種實現,背後的原理和機制你們也都很是熟悉。拋開它們的些許差別不談,共通的思想都是在身份獲得認證經過後,保持一個特定的可溯身份標識(Session ID / Cookie字符串),固然了他們都是以HTTP的Cookie部分保存的。又可知,當瀏覽器禁用了Cookie,爲了讓Session繼續工做,就須要把Session Id附帶到url部分來傳遞。說到這,就引出了咱們想要表達的重點,即在應用服務器和統一認證服務器間傳遞認證信息的字符串標識(姑且稱之Token),Token和Session ID咱們徹底可看成一個同源的東西來看待,也就是說沒有額外需求場景下又剛好使用的Session,徹底能夠拿Session ID直接來用。之因此引出Token,主要是爲了將使用Cookie做爲用戶認證手段的應用統一塊兒來。跨域

系統組件

  • 統一認證服務器(sso.com) - 此服務保存關於用戶的公共信息,各應用均請求該服務進行登陸/註銷和身份有效性驗證。
  • 應用服務器(a.com, b.com) - 此類服務保存用戶的具體業務信息和相應的角色權限, 參與到SSO應用羣中的各個獨立應用站點。

處理流程

  • 登陸

1) 用戶訪問a/b.com,本地域檢查未登陸,跳轉至步驟2(本地域自由選擇使用Session / Cookie來記錄用戶登陸認證標識)
2) sso.com域檢查本地用戶登陸認證信息,用戶是否已登陸,如未登陸先進行登陸,登陸成功後記錄本地用戶登陸認證標識(Session或Cookie),並生成保存一個惟一的Token來標識用戶,而後在URL中攜帶以上Token跳轉至來源應用域(形式如:a/b.com?token=xxxxxx)
3) a/b.com域如接收到URL中的token串後,請求sso.com提供的驗證接口檢查token的真實有效性,若有效則同時返回用戶的關鍵身份信息(如用戶ID、用戶名、頭像URL、...)同時保存本地的用戶登陸認證標識。瀏覽器

  • 註銷

1) 註銷其實能夠分紅兩類場景: (1a)用戶從應用a/b.com本地退出,本地域檢查已經登陸,對本地認證登陸認證標識作銷燬過時處理,並將URL跳轉至sso.com的註銷地址(如:sso.com/logout)。(1b)用戶從應用a/b.com的外部域退出,對於此種情形的應對,須要在各應用登陸後執行一段定時(時長可按實際狀況酌情考慮,如但願準實時就將間隔儘可能小,靈活掌握)輪詢的jsonp腳本攜帶登陸時的Token信息,去請求sso.com檢測是否已退出(如:sso.com/checkExist?token=xxxxxx),如檢測到爲已退出狀態,對本地認證登陸認證標識作銷燬過時處理,但不用再額外通知
sso.com了。
2) sso.com本地域退出或接收到來自外部應用的logout的請求後,將本地域相應Token標識用戶的登陸認證標識作銷燬過時處理。服務器

以上便是一套完整的且具通用性的sso解決方案,實現簡單而對新搭建或舊有系統的改造幾乎無侵入性,只需增長登陸和註銷時所需的處理邏輯。jsonp

補充一點額外的話,有沒有以爲這個方案若是往再更大範圍去想,是徹底能夠看成一套更具開放性的三方登陸(如:Open ID / Oauth)平臺服務,各平臺也無需註冊,權當成一個須要接入sso應用方對接就可完成。url

相關文章
相關標籤/搜索