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 實作各種模式，
| 如果覺得本篇隨筆對你有幫助，請點擊右下方的 【推薦??】，或者給作者 【打賞】，感謝大家的支持，這將成為作者繼續寫作的動力， |
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/39670.html
標籤：C#