用戶端和服務端鑒權認證

鑒權是指驗證使用者通路系統的權力

session-cookie方式：

每當請求到達伺服器端的時候，先去查一下該用戶端有沒有在伺服器端建立seesion，如果有則已經認證成功了，否則就沒有認證。

session-cookie認證主要分四步：

1. 伺服器在接受用戶端首次通路時在伺服器端建立seesion，然後儲存seesion(我們可以将seesion儲存在記憶體中，也可以儲存在redis中，推薦使用後者)，然後給這個session生成一個唯一的辨別字元串,然後在響應頭中種下這個唯一辨別字元串。
2. 簽名。這一步隻是對sid進行加密處理，服務端會根據這個secret密鑰進行解密。（非必需步驟）
3. 浏覽器中收到請求響應的時候會解析響應頭，然後将sid儲存在本地cookie中，浏覽器在下次http請求de 請求頭中會帶上該域名下的cookie資訊
4. 伺服器在接受用戶端請求時會去解析請求頭cookie中的sid，然後根據這個sid去找伺服器端儲存的該用戶端的session，然後判斷該請求是否合法。

Token 方式：

使用基于 Token 的身份驗證方法

1. 用戶端使用使用者名跟密碼請求登入
2. 服務端收到請求，去驗證使用者名與密碼
3. 驗證成功後，服務端會簽發一個 Token，再把這個 Token 發送給用戶端
4. 用戶端收到 Token 以後可以把它存儲起來，比如放在 Cookie 裡或者 Local Storage 裡
5. 用戶端每次向服務端請求資源的時候需要帶着服務端簽發的 Token
6. 服務端收到請求，然後去驗證用戶端請求裡面帶着的 Token，如果驗證成功，就向用戶端傳回請求的資料

總的來說就是用戶端在首次登陸以後，服務端再次接收http請求的時候，就隻認token了，請求隻要每次把token帶上就行了，伺服器端會攔截所有的請求，然後校驗token的合法性，合法就放行，不合法就傳回401（鑒權失敗）。

乍的一看好像和前面的seesion-cookie有點像，seesion-cookie是通過seesionid來作為浏覽器和服務端的連結橋梁，而token驗證方式貌似是token來起到seesionid的角色。其實這兩者差别是很大的。

1. sessionid 他隻是一個唯一辨別的字元串，服務端是根據這個字元串，來查詢在伺服器端保持的seesion，這裡面才儲存着使用者的登陸狀态。但是token本身就是一種登陸成功憑證，他是在登陸成功後根據某種規則生成的一種資訊憑證，他裡面本身就儲存着使用者的登陸狀态。伺服器端隻需要根據定義的規則校驗這個token是否合法就行。
2. session-cookie是需要cookie配合的，居然要cookie，那麼在http代理用戶端的選擇上就是隻有浏覽器了，因為隻有浏覽器才會去解析請求響應頭裡面的cookie,然後每次請求再預設帶上該域名下的cookie。但是我們知道http代理用戶端不隻有浏覽器，還有原生APP等等，這個時候cookie是不起作用的，或者浏覽器端是可以禁止cookie的(雖然可以，但是這基本上是屬于吃飽沒事幹的人幹的事)…，但是token 就不一樣，他是登陸請求在登陸成功後再請求響應體中傳回的資訊，用戶端在收到響應的時候，可以把他存在本地的cookie,storage，或者記憶體中，然後再下一次請求的請求頭重帶上這個token就行了。簡單點來說cookie-session機制他限制了用戶端的類型，而token驗證機制豐富了用戶端類型。
3. 時效性。session-cookie的sessionid實在登陸的時候生成的而且在登出事時一直不變的，在一定程度上安全就會低，而token是可以在一段時間内動态改變的。
4. 可擴充性。token驗證本身是比較靈活的，一是token的解決方案有許多，常用的是JWT,二來我們可以基于token驗證機制，專門做一個鑒權服務，用它向多個服務的請求進行統一鑒權。

OAuth(開放授權)：

OAuth（開放授權）是一個開放标準，允許使用者授權第三方網站通路他們存儲在另外的服務提供者上的資訊，而不需要将使用者名和密碼提供給第三方網站或分享他們資料的所有内容，為了保護使用者資料的安全和隐私，第三方網站通路使用者資料前都需要顯式的向使用者征求授權。我們常見的提供OAuth認證服務的廠商有支付寶，QQ,微信。

OAuth協定又有1.0和2.0兩個版本。相比較1.0版，2.0版整個授權驗證流程更簡單更安全，也是目前最主要的使用者身份驗證和授權方式。

以csdn登陸為例

1. 向使用者請求授權，現在很多的網站在登陸的時候都有第三方登陸的入口，當我們點選等第三方入口時，第三方授權服務會引導我們進入第三方登陸授權頁面。

https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=https://passport.csdn.net/account/login?oauth_provider=QQProvider&state=test

Auth2.0常見的幾個請求參數：

response_type，傳回類型

client_id，應用id,由授權伺服器（qq）在應用送出時頒發給應用。

redirect_uri，登陸成功重定向頁面

oauth_provider，授權提供方

state，由應用給出的随機碼

1. 傳回使用者憑證（code），并傳回一個憑證（code），當使用者點選授權并登陸後，授權伺服器将生成一個使用者憑證（code）。這個使用者憑證會附加在重定向的位址redirect_uri的後面

https://passport.csdn.net/account/login?code=9e3efa6cea739f9aaab2&state=XXX

1. 經過第二部擷取code後，後面的工作就可以交給應用背景去處理了，和使用者的互動就結束了。接下來我的需要擷取Access Token，我們需要用他來向授權伺服器擷取使用者資訊等資源。

   應用背景通過第二步的憑證（code）向授權伺服器請求Access Token，這時候需要以下幾個資訊：

   client_id 辨別應用的id，由授權伺服器（Github）在應用送出時頒發給應用

   client_secret 應用和授權伺服器之間的安全憑證，由授權伺服器（Github）在應用送出時頒發給應用

   code 第一步中傳回的使用者憑證redirect_uri 第一步生成使用者憑證後跳轉到第二步時的位址

   state 由應用給出的随機碼

2. 授權伺服器同意授權後，傳回一個資源通路的憑證（Access Token）。
3. 應用通過第四步的憑證（Access Token）向資源伺服器請求相關資源
4. 資源伺服器驗證憑證（Access Token）通過後，将該應用請求的資源傳回。