摘要：系統從認證中心得到校驗成功的結果后，則可以認為用戶已登錄。認證中心發現用戶未登錄沒有，將用戶引導至登錄界面。用戶提交登錄信息到認證中心。

首先讓我們分析一下一個簡單的登錄是怎么實現的。

一個簡單的登錄流程

用戶輸入url訪問站點，接受用戶請求后判斷用戶是否已經登錄，若未登錄則跳轉到登錄頁面

用戶訪問登錄頁面，填寫并提交登錄表單

web應用對登錄表單進行驗證，若驗證失敗，則返回錯誤信息給用戶；若驗證成功，則將用戶相關的信息（通常為用戶id等信息）寫入到當前的session中，將session id以cookie的形式發送給用戶（同時可以將session中的身份信息以cookie的形式發送給用戶，這個是可選的，使用該cookie可以實現自動登錄，如下面的“登錄分析圖”中所示）。

用戶登錄后，后續的訪問中會將其獲得的包含session id的cookie傳遞給web應用，若web應用能根據session id從session中獲取到相應的身份信息（甚至進一步從數據庫查找到相關的用戶數據），則代表用戶成功登錄。

退出登錄
退出登錄主要包括以下兩個流程

銷毀session信息 （在服務端銷毀）

銷毀客戶端的相關cookie（包含session id的cookie）

通常來說，服務器端的session會有一定的過期時間，同樣的，客戶端中包含session id的cookie也有過期時間。若用戶登錄后，長時間沒有發出訪問請求，則等到用戶再次訪問時，可能服務端的session或客戶端的cookie已經失效，導致服務器判斷用戶為“未登錄”，而實際上用戶并沒有退出登錄過。可以通過實現“自動登錄”來解決這個問題，即在session失效的時候，可以重新自動登錄。

自動登錄的基本思路:

在用戶登錄后，除了生成session id對應的cookie，還會生成一個包含用戶身份信息的cookie（假設這個cookie的key為identity）。identity cookie包含的信息可以有：用戶id，用戶authKey（這個比較重要，authKey的功能有點類似于password），cookie持續時間等。為了達到自動登錄的目的,通常會將該cookie的過期時間設置的特別長（可以是一個星期甚至一個月）。

在用戶session失效后，用戶再次訪問web應用，會帶上identity cookie（因為該cookie的有效期較長）。web應用首先判斷用戶為“未登錄”狀態（因為session失效了）。

web應用嘗試通過identity cookie為用戶自動登錄。應用從identity cookie中獲取“用戶id”和“用戶authKey”，通過與數據庫中的數據進行對比，校驗“用戶authKey”的有效性。

用戶authKey認證有效后，web應用為用戶生成新的session，并將新的session id放入cookie發送給用戶。（即用戶登錄成功的標志為獲取到包含session id的cookie）

yii1.1原生登錄分析

原文件和圖片下載百度云盤鏈接

yii2原生登錄分析

原文件和圖片下載百度云盤鏈接

cookie，session是實現登錄的核心

對應關系鏈： 客戶端的cookie（包含了session id） ---> session id對應服務器端的session（包含了用戶的身份信息，如id） ---> 根據session中的信息，可以進一步從數據庫中獲取用戶的詳細信息（甚至是其相應的權限）

單點登錄（Single sign-on，縮寫為 SSO），又譯為單一簽入，一種對于許多相互關連，但是又是各自獨立的軟件系統，提供訪問控制的屬性。在擁有這項屬性的環境中，當用戶在某個系統登錄時，就可以獲取所有系統的訪問權限，不用對每個單一系統都逐一登錄。這項功能通常是以輕型目錄訪問協議（LDAP）來實現，在服務器上會將用戶信息存儲到LDAP數據庫中。相同的，單一注銷（single sign-off）就是指，只需要單一的注銷動作，就可以結束對于多個系統的訪問權限。（即，在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統；用戶只需要退出登錄一次就可以退出所有的應用系統）

降低訪問第三方網站風險（用戶密碼不存儲或外部管理）。

用戶不需要在不同的站點使用不同的用戶名和密碼，減少“密碼疲勞”（password fatigue ）。

減少在使用不同站點時花費時間來重新輸入密碼進行身份驗證。

降低IT成本。

當用戶第一次訪問應用系統1的時候，因為還沒有登錄，會被引導到認證系統中進行登錄（1）

根據用戶提供的登錄信息， 認證系統進行身份校驗，如果通過效校驗，返回給用戶一個認證的憑據ticket（2）

用戶重新訪問應用系統1，此時會帶上ticket。應用系統1接受到請求后會把ticket發送到認證系統進行校驗，檢查ticket的合法性；若ticket合法性驗證通過（代表用戶已經登錄），則用戶可以訪問應用系統1

用戶再訪問別的應用的時候（3，5）也會將這個ticket 帶上，作為自己認證的憑據，應用系統接受到請求之后會把ticket送到認證系統進行效驗，檢查ticket的合法性（4，6）。如果通過效驗，用戶就可以在不用再次登錄的情況下訪問應用系統2和應用系統3了。

總結：ticket是整個系統的核心，ticket會在用戶，應用系統，認證系統的交互中傳輸，最終達到實現單點登錄的目的。ticket是所有系統對用戶的統一的認證標志。

Q1：ticket是什么？由什么組成？
正如前面所說，ticket是所有系統對用戶的統一的認證標志。在具體的實現中，我們可以用cookie來實現ticket的功能。最簡單的，一個包含session id的cookie就可以看成是一個ticket。在后續對具體實現的分析中，我們會更深入地理解ticket。出于安全需要，通常我們會對ticket進行加密。要實現SSO的功能，讓用戶只登錄一次，就必須讓應用系統能夠識別已經登錄過的用戶。應用系統應該能對ticket進行識別和提取，通過與認證系統的通訊，能自動判斷當前用戶是否登錄過，從而完成單點登錄的功能。

Q2：單點登錄在技術實現上有哪些分類？
在技術實現上，單點登錄可以分為跨子域單點登錄和完全跨域單點登錄

Q3：什么是跨子域單點登錄？其實現的具體思路是什么？
跨子域單點登錄即在具有相同根域名的站點之間實現單點登錄。例如，有以下站點a.example.com, b.example.com, p.example.com(認證中心)，它們都有一個共同的根域名“example.com”。在單點登錄寫cookie時，把cookie的域設為它們共同的父域（即“example.com”），這樣在不同的子域名下都可以使用同一個cookie（即ticket）；與此同時，可以讓多個系統共享session信息。

Q4：什么是完全跨域單點登錄？其實現的具體思路是什么？
完全跨域單點登錄即具有不同根域名的站點之間實現單點登錄。實現思路：每個站點需要有自己的ticket（A-tikcet，B-ticket，P-ticket）；當訪問應用系統（A，B）時，若沒有相應的ticket，則自動重定向到認證系統（P），在認證系統認證獲得P-ticket后重定向到應用系統（A或B），用P-tikcet換取相應的A-ticket或B-ticket；注銷的時候要注銷所有的ticket(P-ticket,A-ticket,B-ticket)

Q5：Q3中共享cookie的方式存在什么局限？
首先，應用群域名得統一；其次，應用群各系統使用的技術（至少是web服務器）要相同，不然cookie的key值（tomcat為JSESSIONID，php為PHPSESSID）不同，無法維持會話，共享cookie的方式是無法實現跨語言技術平臺登錄的，比如java、php、.net系統之間；第三，cookie本身不安全。

跨子域單點登錄的實現相對比較簡單，可以基于cookie來實現，基本思想如下：

前提： 應用群中各個站點的域名需要統一，即具有相同的根域名；應用群使用的技術要相同，這樣才能夠維持回話（例如tomcat下cookie的key值為JSESSIONID，而PHP技術棧下則為PHPSESSID）

在前面所述的“web單點登錄的基本思路”的基礎上，將ticket具體實現為cookie中的session id，并且可以省略應用到認證中心對ticket進行校驗的步驟。

具體圖示如下：

1.當用戶訪問系統1（域名為a.example.com）時,系統檢測到用戶的請求中沒有ticket（即沒有相應的cookie），則判斷用戶未登錄，將用戶重定向到認證中心(帶上系統1的url，則認證完后認證中心可將用戶重定向會系統1)

2.用戶提交登錄表單到認證中心，驗證通過后創建相應的session。將session id作為ticket，以cookie的方式發送給用戶，并將用戶重定向到系統1。（注意，cookie的域為根域“example.com”）

3.用戶重定向到系統1(此時會帶上相應的cookie作為ticket)。系統1檢測到有ticket，則向認證中心發起請求，驗證ticket的有效性。

4.認證中心驗證ticket的有效性（即確實有對應的session），將校驗結果返回給系統1

5.系統1從認證中心得到校驗成功的結果后，則可以認為用戶“已登錄”。

6.用戶繼續訪問系統2(因為系統2的域名為“b.example.com”,其根域名也為“example.com”,故此時會帶上相應的cookie作為ticket)。系統2檢測到有ticket，則向認證中心發起請求，驗證ticket的有效性。

7.認證中心驗證ticket的有效性（即確實有對應的session），將校驗結果返回給系統2。

8.系統2從認證中心得到校驗成功的結果后，則可以認為用戶“已登錄”。

完全跨域單點登錄的實現思路正如前面所述，這里復述一下：
1.每個站點需要有自己的ticket（假設：系統1為A-tikcet，系統2為B-ticket，認證中心為P-ticket）
2.當訪問應用系統（系統1，系統2）時，若沒有相應的ticket，則自動重定向到認證系統（P），在認證系統認證獲得P-ticket后重定向到應用系統（系統1或系統2），用P-tikcet換取相應的A-ticket或B-ticket；注銷的時候要注銷所有的ticket(P-ticket,A-ticket,B-ticket)

具體圖示如下:
注意： 在具體的實現中，可以用cookie來實現tikcet。ticket可以是包含session id的cookie。

1.用戶訪問系統1，系統1發現用戶未登錄(沒有A-ticket)，跳轉至認證中心，并帶上系統的url作為參數（即回調url，這樣認證后就可以跳轉回來了）。

2.認證中心發現用戶未登錄(沒有P-ticket)，將用戶引導至登錄界面。

3.用戶提交登錄信息到認證中心。

4.認證中心校驗用戶的登錄信息，通過驗證后，創建一個全局session，生成一個綁定當前session的P-ticket。然后將P-ticket發送給用戶，并將用戶重定向到系統1（注意，此時會帶上P-ticket）。

5.系統1接收到帶有P-ticket的請求后，會向認證中心發出一個請求，驗證P-ticket的有效性。

6.認證中心接收到系統1的校驗請求，將校驗結果返回給系統1。同時若驗證通過則會將映射關系(P-ticket,系統1)記錄到一個映射表中（稱該表為“注冊系統表”，即記錄那些登錄的子系統與P-ticket的對應關系，這樣在用戶注銷的時候就可以向相應的子系統發送請求，銷毀相應的局部session）。

7.系統1接受到認證中心的校驗結果，若校驗通過，則認為用戶是“已登錄”，系統1在自身系統為用戶創建一個session（局部session），并生成一個綁定該session的A-ticket，同時將映射關系（A-ticket，P-ticket）記錄到自己的一個映射表中（稱該表為“ticket映射表”）。然后系統1將A-ticket發送給用戶，在后續用戶對系統1的訪問中，會帶上A-ticket，則可以通過A-ticket判斷用戶是否已經登錄。

8.用戶訪問系統2，系統2發現用戶為登錄（沒有B-ticket）,跳轉到認證中心（此時對認證中心的訪問會帶上P-ticket），并帶上系統2的url作為參數（即回調url，這樣認證后就可以跳轉回來了）。

9.認證中心發現用戶已經登錄（因為用戶已經持有P-ticket），確認P-ticket的有效性后即可認為用戶“已登錄”。認證中心將用戶重定向到系統2（帶上P-ticket）。

10.系統2接收到帶有P-ticket的請求后，會向認證中心發出一個請求，驗證P-ticket的有效性。

11.認證中心接收到系統2的校驗請求，將校驗結果返回給系統2。同時若驗證通過則會將映射關系(P-ticket,系統2)添加到“注冊系統表”。

12.系統2接受到認證中心的校驗結果，若校驗通過，則認為用戶是“已登錄”，系統2在自身系統為用戶創建一個session（局部session），并生成一個綁定該session的B-ticket，同時將映射關系（A-ticket，P-ticket）記錄到自己的一個映射表中（稱該表為“ticket映射表”）。然后系統2將B-ticket發送給用戶，在后續用戶對系統2的訪問中，會帶上B-ticket，則可以通過B-ticket判斷用戶是否已經登錄。

注銷圖示：

1.用戶向系統1發起注銷請求（會帶上A-ticket）。

2.系統1根據映射表“ticket映射表”，取出相應的P-ticket。系統1向認證中心發起注銷請求（帶上P-ticket）。

3.認證中心接收到注銷請求后，驗證P-ticket的有效性。若P-ticket有效，則銷毀本地的全局session(根據P-ticket)。認證中心從“注冊系統表”中查找出與P-ticket相關的所有系統，向所有相關的系統發送注銷局部會話請求。

4.系統2接收到認證中心的“注銷局部會話”請求，根據P-ticket從“ticket映射表”中取出相應的B-ticket，根據B-ticket銷毀本地局部會話。

5.系統1接收到認證中心的“注銷局部會話”請求，根據P-ticket從“ticket映射表”中取出相應的A-ticket，根據A-ticket銷毀本地局部會話。

值得注意的地方：
1.在上面的實現中，我們可以看到P-ticket是需要在各個端傳遞的，故出于安全考慮，應該對P-ticket做一些安全性處理，如加密等。