OAuth2.0 基礎知識

Tips：本篇已加入，.Net core 3.1 使用IdentityServer4 實現 OAuth2.0 --閱讀目錄  可點擊查看更多相關文章。

 

前言

若是你們英語比較好 能夠看下 OAuth2.0官網（https://oauth.net/2/），固然英語很差也不要緊 咱們看一下，下面一段描述：

OAuth（開放受權）是一個開放標準，容許用戶受權第三方網站訪問他們存儲在另外的服務提供者上的信息，而不須要將用戶名和密碼提供給第三方網站或分享他們數據的全部內容.

 

---

 

開始

作過微信受權的同窗們應該都知道，本身開發的應用獲取用戶openid的過程就是一個OAuth認證受權的流程，

咱們看一下微信官方的登陸流程圖：

 

 

 

 這個就是一個 符合OAuth 受權碼模式（authorization code）的流程，當咱們須要獲取 微信的openid（資源）時，不是在開發者應用上讓用戶輸入微信號和密碼（其實也沒辦法輸入），

須要用戶主動接受受權獲取到code，開發者拿着code和事先在微信平臺註冊的appid和appsecret，去訪問微信服務器換取 openid（資源）。

 

（題外話）其實實際操做上可能還要複雜一點：用戶受權後其實拿到的時code和iv，而且這個iv用了一次就失效了， 而後服務器後臺根據code+appid+appsecret向微信後臺發送請求獲取openid+session_key 最後服務器後臺根據session_key+IV解密encryptedData（AES解密三個參數：密文encryptedData，密鑰session_key，偏移向量iv）

 

 

 

 

 

可能你們有點暈乎了怎麼一上來直接講 受權碼模式 了，以後的章節中會具體講解各類模式，這裏主要是讓你們先有點感受。

---

 

名詞定義

（1）Third-party application：第三方應用程序， 即上圖中的開發者作的微信小程序。

（2）HTTP service：HTTP服務提供商，本文中簡稱"服務提供商"，即上圖中的微信。

（3）Resource Owner：資源全部者，本文中又稱"用戶"（user）。

（4）User Agent：用戶代理，能夠時瀏覽器，app或者是上圖描述中的 微信小程序。

（5）Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器。

（6）Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，能夠是同一臺服務器，也能夠是不一樣的服務器。

 

---

 

認證類型

官網上描述的類型有如下幾種： 

• Authorization Code
• PKCE
• Client Credentials
• Device Code
• Refresh Token
• Legacy: Implicit Flow
• Legacy: Password Grant

本系列主要是講解Web端的OAuth會講述裏面的 5中類型（不包括 PKCE和 Device Code）

可是我仍是會大概說一下這兩種模式

PKCE模式 ：適用於功能邏輯主要在客戶端完成的native app。由於native app沒有瀏覽器那樣的cookie支持，CP服務器沒有session這樣的東西來保存state參數從而防止CSRF，因此使用PKCE的code_verifier和code_challenge來防止CSRF。 Device Code 設備代碼： 設備流中的無瀏覽器或受輸入限制的設備使用設備代碼受權類型，以將先前得到的設備代碼交換爲訪問令牌。設備代碼受權類型值爲urn:ietf:params:oauth:grant-type:device_code.

 

 

 

 

以後的章節主要重點講解 

• 客戶端模式（client credentials）
• 密碼模式（resource owner password credentials）
• 簡化模式（implicit）
• 受權碼模式（authorization code）

而Refresh Token 存在於各個模式之中，隨着 .netcore 的流行，IdentityServer4也隨之風靡，下面一節中會介紹一下 IdentityServer4 裏的一些名詞，便於同窗們理解以後章節 用ID4 實現各類模式。

 

 

若是以爲本篇隨筆對你有幫助，請點擊右下方的 【推薦👍】，或者給做者 【打賞】，感謝你們的支持，這將成爲做者繼續寫做的動力。