PHP中單點登入Cookie分析與實現-php教程-PHP中文網

單一登入SSO（Single Sign-On）是身分識別管理的一部分。 SSO的一種較為通俗的定義是：SSO是指訪問同一伺服器不同應用中的受保護資源的同一用戶，只需要登入一次，即透過一個應用程式中的安全驗證後，再訪問其他應用程式中的受保護資源時，不再需要重新登入驗證。希望本文對大家有幫助。

什麼是SSO？

單一登入SSO（Single Sign-On）是身分識別管理的一部分。 SSO的一種較為通俗的定義是：SSO是指訪問同一伺服器不同應用中的受保護資源的同一用戶，只需要登入一次，即透過一個應用程式中的安全驗證後，再訪問其他應用程式中的受保護資源時，不再需要重新登入驗證

SSO的用途：

#目前的企業應用程式環境中，往往有許多的應用系統，淘寶、天貓、愛淘寶等等產品和如辦公室自動化（OA）系統，財務管理系統，檔案管理系統，資訊查詢系統等等。這些應用系統服務企業的資訊化建設，為企業帶來了很好的效益。但是，使用者在使用這些應用系統時，並不方便。使用者每次使用系統，都必須輸入使用者名稱和使用者密碼，進行身份驗證；而且應用系統不同，使用者帳號就不同，使用者必須同時牢記多套使用者名稱和使用者密碼。特別是對於應用系統數目較多，使用者數目也很多的企業，這個問題特別突出。問題的原因並不是系統開發出現失誤，而是缺乏整體規劃，缺乏統一的使用者登入平台，使用SSO技術可以解決以上這些問題

##SSO的好處：

方便使用者：從使用者實際使用角度考慮

使用者使用應用系統時，能夠一次登錄，並多次使用。使用者不再需要每次輸入使用者名稱和使用者密碼，也不需要牢記多套使用者名稱和使用者密碼。單一登入平台能夠改善使用者使用應用系統的體驗。

方便管理員：從日常維護管理角度考慮

現在很多大的網路公司都會有很多的應用，例如以下是淘寶網的截圖：

天貓聚划算頭條等都是不同的應用，有的甚至採用完全不同的域名，但是所有在淘寶註冊的用戶都是使用的一套用戶名和口令，如果在這些系統直接切換做不到登陸狀態的同步，體驗是非常差的。再舉個栗子，很多公司內部系統也有很多個，比如HR系統，財務系統，考勤系統等等，如果員工在一個系統登陸了，跳轉到另外一個系統還需要登陸，就會讓人很不爽. ..

基於此，SSO(Single Sign On)應運而生。當然，我們來現實這個需求的方法有很多種，使用Cookie是其中比較簡單的方式，主要需要解決的問題是:Cookie是不能跨域傳遞的，如何將一個域的Cookie通知給其它應用(不在同一個域)？

so，如果你對cookie機制不太熟悉，請先google，並大致了解為什麼cookie會設計成不能跨域等相關問題。

系統管理員只需要維護一套統一的使用者帳號，方便、簡單。相較之下，系統管理員以前需要管理很多套的使用者帳號。每一個應用系統就有一套使用者帳號，不僅為管理上帶來不方便，而且，也容易出現管理漏洞。

簡化應用系統開發：從應用程式擴充角度考慮

開發新的應用系統時，可直接使用單一登入平台的使用者認證服務，簡化開發流程。單一登入平台透過提供統一的認證平台，實現單一登入。因此，應用系統並不需要開發使用者認證程序。

如何實現？

SSO有以下幾種方式實作

共享Cookie

當我們的子系統都在一個父級域名下時，我們可以將Cookie種在父域下，這樣瀏覽器同域名下的Cookie則可以共享，這樣可以透過Cookie加解密的演算法取得使用者SessionID，從而實現SSO。

但是，後面我們發現這種方式有幾種弊端：

a. 所有同域名的系統都能取得SessionID，易被修改且不安全；
b. 跨域無法使用。

ticket驗證，我們目前採取的是這種方式

這種實作的SSO有以下幾個步驟：

a. 使用者造訪某個子系統，發現如果未登錄，則引導使用者跳到SSO登入頁面；
b. 判斷SSO是否已經登入；
c. 如果已經登錄，直接跳到回調地址，並返回認證ticket；
d. 如果未登錄，用戶正確輸入用戶名/密碼，認證通過跳到回調地址，並返回認證ticket；
e. 子系統獲取ticket，調用SSO取得用戶uid等信息，成功後讓用戶登入。

前面已經說了，如何透過Cookie來實現SSO，主要是如何解決跨域問題。首先來談談Set-Cookie中的domain屬性。

Cookie domain

為了讓Http協定在一定程度上保持上下文，server在回應的頭部可以加入Set-Cookie來寫入一些數據到客戶端，Set-Cookie中的

domain欄位用來表示這個cookie所在的網域。

栗子：

我們造訪www.cookieexm.com，如果server在回傳頭部加入了Set-Cookie,如果不指定domain,那麼預設這個cookie的網域就是www.cookieexm.com，也就是只有造訪www.cookieexm.com時客戶端才會把這個cookie回給服務端。
如果我們指定domain為.cookieexm.com，那麼客戶端在造訪以下網域：www.cookieexm.com www1.cookieexm.com a.cookieexm.com ***.cookieexm.com 時都能夠把cookie回傳。

所以，我們得出一條結論：客戶端對cookie的domain的匹配是從結尾進行匹配的，有了這個基礎，我們就可以實現我們的SSO登陸了。

cookie中需要注意的

設定為http-only

涉及登入憑證（如票據或使用者名稱）應該加密

cookie不能存放隱私資料

具體方案

假設我們需要在以下子系統**.a1.a2 **.b1 .b2 **.c1.c2間實現單一登錄，首先我們需要一個專門用於單點登陸的認證系統(sso.s1.s2)。假設目前系統處於未登入狀態，造訪www.a1.a2為例：

#分別看一下每個步驟作用：

請求www.a1 .a2

www.a1.a2收到請求，檢查是否攜帶登入的cookie，目前沒有登陸過，那麼重定向到sso認證中心
SSO提供登陸窗口，使用者輸入使用者名稱命令。 SSO系統驗證使用者名稱和口令

這一步驟是關鍵，如果登入成功，首先把SSO系統的Cookie放到客戶端；同時，將使用者的認證資訊傳遞透過重定向傳遞給業務方，注意，這個傳遞明顯不能透過cookie來傳遞（不同域嘛），一般是透過加密的querystring。

業務方的驗證系統收到sso認證訊息，再進行認證
業務方認證通過之後，把認證結果的cookie寫入到.a1.a2，至此，SSO認證完成
重定向到業務系統www.a1.a2,由前面的結論可知，此時所有以.a1.a2結尾的業務系統都可以使用這個認證之後的cookie

response

說明:
業務認證系統不一定存在，有些不是太敏感的系統可以直接從SSO Authorization重定向到業務系統，並把SSO的認證資訊帶過去。

承接上文，此時，若使用者存取www.b1.b2應用，如下圖所示：

與存取www.a1.a2不同的是我們在重定向到SSO Authorization時已經不需要再去輸入用戶名，因為sso.s1.s2此時已經存有cookie，直接用cookie驗證。

以上，就是一個簡單的基於Cookie的登陸系統。

其中幾個問題需要重點解決

如何有效率地儲存大量臨時性的信任資料
如何防止資訊傳遞過程被竄改
#如何讓SSO系統信任登入系統和免登系統
對於第一個問題，一般可以採用類似與memcached的分散式快取的方案，既能提供可擴展資料量的機制，也能提供高效存取

對於第二個問題，一般採取數位簽名的方法，要么通過數位證書簽名，要么通過像md5的方式，這就需要SSO系統返回免登URL的時候對需驗證的參數進行md5加密，並帶上token一起返回，最後需免登的系統進行驗證信任關係的時候，需把這個token傳給SSO系統，SSO系統通過對token的驗證就可以辨別信息是否被改過

#對於最後一個問題，可以透過白名單來處理，說簡單點只有在白名單上的系統才能請求生產信任關係，同理只有在白名單上的系統才能被免登入。