1.cookie-session

1. cookie

cookie簡單來說就是瀏覽器客戶端在請求時會攜帶的一個字段數據，常用與保存當前用戶狀態并在請求時攜帶給服務端驗證。

2. session

session簡單來說就是服務單對于每一個用戶生成一個用戶會話標識session /session id，并返回給客戶端，客戶端在每次請求時攜帶這個會話標識就可以判斷當前用戶的會話狀態。

3. 鑒權原理

1. 初次登錄時，服務端將當前用戶的登錄狀態生成一個session/session id
2. 服務端將session id（sid)） 設置到cookie 中隨請求返回。
3. 下次請求時瀏覽器自動攜帶當前域名下的cookie，服務端獲取到sid之后，根據sid的信息來匹配上對應的session,然后判斷該請求是否合法。

4. 缺點

1. 不安全， sid保存到cookie容易被篡改
2. 對移動端支持不優化，僅可在瀏覽器web應用中使用
3. 依賴瀏覽器請求頭攜帶cookie，如果瀏覽器禁用cookie會造成該方案無法使用

2.token

1.token

token指的是由服務端生成的一個專門用于判斷用戶身份的令牌，客戶端可以攜帶這個令牌來獲取數據。這個token一般來說會存在時效性，過期即作廢，需要重新申請。因此這也衍生出了兩種不同的token。

2.token的分類

1. Access token

用戶校驗用戶信息的token，在每次請求時發送給服務器

1. Refresh token

用戶重新火球Access token，在Access token過期，服務器返回401時發送給服務器，服務器根據Refresh toekn的有效性重新簽發一份新的Access toekn返回給瀏覽器。

3.鑒權原理

1. 初次登錄，服務器生成一份toekn并返回給客戶端
2. 客戶端收到token后將其保存到瀏覽器本地，一般為localStorage
3. 后續請求時客戶端在請求頭中攜帶token,一般為Authoration 字段
4. 服務端判斷token是否有效，有效則正常請求，無效返回401

以下階段為使用Refresh token 場景下

1. 如果使用Refresh toekn方案，此時客戶端接受到401 后，會攜帶Refresh toen再次請求服務器
2. 服務器收到Refresh toekn后，根據其有效性自動重新簽發一份token并返回
3. 瀏覽器接收到新token之后覆蓋本地token并重新發發送請求

Refresh token方案下， Refresh toekn是在初次登錄是和Access token一起生成并返回給客戶端客戶端

3.JWT

1.jwt（json web token）

jwt本質上就是token鑒權的一種實現方式,通過服務端臨時深成一個編碼的toekn字符串來返回給客戶端。

2.組成

jwt主要有三部分組成，分別是Header,Payload,Signature(簽名）

jwt是一段很長的字符串，有點號（.）分割為以上的三部分

• Header一般包含token的類型，例如是JWT；加密使用的算法
• Payload一般是保存用戶的一部分信息以及一些官方字段，包括iss（簽發人），exp（過期時間），nbf(生效時間）等等。
• Sginature 一般是一個簽名，這個簽名是將一個密鑰通過Header里面的加密算法加密過后的字符串。密鑰保存再當前服務端。

3.鑒權原理和token一樣

4.單點登錄（SSO）

1.單點登錄介紹

所謂單點登錄，指的是在登錄了某一個系統之后，再去使用其子系統或相關系統是，可以自動獲取到用戶信息，不需要重復登錄的一種技術。單點登錄主要分為兩種類型，即同域名和不同域名

2.同域名單點登錄

1.前提條件

• 兩個系統均使用cookie攜帶用戶信息（可以是cookie-session ,也可以是token）
• 兩個系統的一級或者二級域名相同（同一個主域名）

2.鑒權原理

1. 客戶端登錄系統1后，將其對應的cookie信息保存下來，并設置cookie的Domain字段為主域名
2. 客戶端訪問系統2時，在發送請求時會自動攜帶上與當前系統主域名相同的cookie信息到服務端請求數據，此時服務端就可以獲取到用戶信息了。

3.不同域名下的單點登錄

1.CAS 中央授權系統

用于判斷用戶登錄狀態并為需要的系統簽發用戶登錄憑證

2.鑒權原理

1. 用戶當訪問系統1時，發現用戶未登錄，調用CAS的登錄登錄模塊并跳轉至CAs的登錄界面
2. 用戶在CAS上登陸之后，服務端生成一份TGC存放到session中，并生成一份ST授權信息，攜帶ST重定向系統1的頁面。將TGC寫入到當前中央授權系統的Domain下。
3. 系統1在加載后獲取到ST，拿著ST向CAS校驗授權有效性，若授權有效則系統1將ST作為憑證參與后續請求會話。
4. 此時再去訪問系統2，首先判斷用戶未登錄跳轉至CAS，攜帶Domain中的TGC發送請求判斷登陸狀態
5. 判斷已登錄后跳轉至系統2的地址并附上ST憑證

5.OAuth 2.0(三方登錄）

1.OAuth

OAuth是一個開放的標注，允許第三方網站訪問提供商服務并獲取對應的用戶信息而無需再忍第三方網站單獨登錄

2.授權碼模式

1. 客戶端點擊第三方登錄，發送請求
2. 服務端收到請求之后，會重定向到授權器
3. 授權服務器返回授權網站，判斷用戶是否登錄，登陸之后會詢問是否為這個網站授權
4. 用戶同意后，會跳轉會原來的網站地址，并且攜帶一個授權碼
5. 服務端拿到授權碼之后，通過授權碼向授權服務器發送請求獲取token
6. 授權服務器將對應的token信息發送至當前服務端，服務端會把token返回給瀏覽器，在后續請求時都會攜帶

3.隱藏式模式

1. 客戶端點擊第三方登錄直接重定向到授權頁面
2. 授權成功后，在重定向到前端頁面時，直接攜帶一個token挑戰
3. 跳轉成功后將token保存下來
4. 每次請求用戶信息是直接攜帶token向授權服務器發送請求

6.掃碼登錄

1.掃碼登錄

掃碼登錄一般是使用一些移動端設備，為pc端授權登錄的場景

2.登錄原理

待掃碼階段

1. pc端點擊掃碼登陸之后，向服務端請求一個獲取二維碼的請求
2. 服務端接收請求后，生成一個uuid作為二維碼id并將uuid和pc設備信息關聯起來存儲到redis中，然后返回給pc端。
3. pc端接收到二維碼id之后，通過canvas價格二維碼id渲染二維碼，等待移動端掃碼。并且開始輪詢查詢二維碼狀態，發現二維碼過期之后會提示。

已掃碼待確認階段

1. 使用移動端設備掃碼，掃碼后會解析二維碼圖像并生成對應的id
2. 移動端將對應的id發送給服務端，并查詢到pc登錄設備信息返回。并生成一個臨時token用于移動端確認
3. 移動端彈出確認界面，并展示pc登錄的狀態，比如登錄時間，地點等等

已確認階段

1. 移動端確認登錄，攜帶上一步獲取的臨時token發送到服務端
2. 服務端驗證token有效性，通過驗證后簽發一個正式的token返回給PC端。
3. Pc端獲取到token信息后，二維碼展示為已確認狀態，并跳轉至使用頁面完成登錄。

7.一鍵登錄

1.一鍵登錄

一鍵登錄指的是客戶端直接從用戶系統中獲取到對應的手機號，直接使用該手機號完成登錄。一般適用于原生應用或小程序應用

2.登錄原理

1. 用戶點擊一鍵登錄
2. 通過運營商SDK調用，喚起配置頁面，SDK會先發送手機號掩碼到運營商服務器，請求成功后跳轉至確認頁面，顯示出手機掩碼及運營商協議等供用戶確認。
3. 同意授權登錄后，SDK會請求本次取號的token，成功后將token返回給客戶端
4. 客戶端將取號token發送到服務器，服務器攜帶攜帶取號token調用運營商的一鍵登錄接口獲取用戶手機號，服務端使用手機號完成登錄流程，生成token返回給客戶端。