當我們在登錄一些網站的時候，需要第三方的登錄，比如，現在我們要登錄簡書https://www.jianshu.com/sign_in，我們使用微博登錄，點擊下方的一個微博的小按鈕，就會出現這么一個地址https://api.weibo.com/oauth2/authorize?client_id=1881139527&redirect_uri=http%3A%2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fweibo%2Fcallback&response_type=code&state=%257B%257D，乍一看，這是什么玩意啊，我們來分解下：
https://api.weibo.com/oauth2/authorize? client_id=1881139527& redirect_uri=http%3A%2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fweibo%2Fcallback& response_type=code& state=%257B%257D
現在就要引出今天的主角了，OAuth2
那什么是OAuth2呢？
https://oauth.net/2/這是官網
https://open.weibo.com/wiki/授權機制，這是微博的授權機制
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html，這是阮一峰寫的一篇對于OAuth2的介紹，
OAuth2.0是一個委托協議，它可用讓那些控制資源的人允許某個應用代表這些人，而不是假冒和模仿這喜人，這個應用從資源的所有者哪里得到授權（Authorization）和Access Token，隨后就可以使用這個Access Token來訪問資源，（這里提到的假冒和模仿就是指在客戶端復制一份用戶名和密碼，從而獲取回應的權限），是關于授權（Authorization）的，客戶端應用可以請求Access Token，使用Tooken就可以訪問API資源了，在上述的例子中，是微博給簡書授權，
讓客戶端應用可以代表資源所有者（通常是用戶）來訪問被保護的資源，如下圖：
資源所有者（Resource Owner），他擁有訪問API資源的權限，并且他還可以委派權限（delegate）給其他應用來訪問API，資源所有者通常是可以使用瀏覽器的人，
被保護的資源（Protected Resource）就是資源所有者擁有權限去訪問的組件，它可以是很多種形式的，但是WebApi的形式還是最常見的，
客戶端（Client）應用就是代表資源所有者訪問被保護資源的一個軟體，注意它既不是瀏覽器，也不是給你錢讓你開發軟體的人，在OAuth2里面，它是指被保護的API資源的消費者，
授權服務器（AS）是被受保護的資源所信任的，它可以發行具有特定目的的安全憑據給客戶端應用，這個憑據就叫做OAuth的Access Token，
授權，如下圖
授權種類：
1、Authorization Code
2、Implicit
3、Resource Owner Password Credentials，直接使用密碼憑據（用戶名和密碼）作為授權來獲得Access Token，只有當資源所有者和客戶端之間高度新人的時候并且其它授權方式不可用的時候才可以使用這種授權方式，
4、Client Credentials，有時候，資源或者叫資源服務器，并不屬于某個最終用戶，也就是沒有資源所有者對該資源負責，但是客戶端應用肯定還是要訪問這些資源，這時候就只能使用Client Credentials這種授權方式了，
其他重要角色和組件：
1、資源所有者Resource Owner
2、客戶端Client
3、被保護資源 Protected Resource
4、授權服務器Authorization Server
5、Access Token，它是用來訪問被保護資源的憑據，授權服務器只是方形Token，被保護資源驗證Token，客戶端隊友Access Token應該是完全健忘的，
6、Scopes，被保護資源那里的一套權限，具有疊加性
7、Refresh Token，用來獲得Access Token的憑據，客戶端是用Refresh Token來請求信的Access Token
通過refresh token來取得新的access token的流程
重要端點：
1、授權端點（Authorization Endpoint）是用來和資源所有者互動的，資源所有者在這里進行登錄（身份認證），然后通過該端點可以對客戶端進行授權（ Authorization Grant），授權服務器首先要驗證資源所有者的身份，但是驗證的方式并不在OAuth2的協議范圍內，
2、Token端點（Token Endpoint），客戶端通過向Token端點展示它的授權（Authorization Grant）或Refresh Token來獲取Access Token，除了Implicit之外所有的授權型別都需要使用該端點，因為Implicit和Access Token是直接發行的，
OpenId Connect（OIDC）
身份認證和授權，OAuth2不是身份認證（Authentication）協議，OpenId Connect可以進行身份認證（Authentication），
一個比喻，授權，就好比生牛奶（多用途原料）；身份認證，就好比奶茶（一個最終產品），以牛奶為主原料，OAuth2，是生牛奶，眾多web安全架構的一種多用途的基本成分，OIDC，好比奶茶，基于OAuth2的身份認證協議，添加了一些組件來提供身份認證的能力，
更高級的協議，擴展并代替了OAuth2，OpenID Connect是建立在OAuth2協議上的一個簡單的身份標識層，所以OpenID Connect兼容OAuth2，使用OpenID Connect，客戶端應用可以請求Identity Token，它會和Access Token一同回傳給客戶端應用，這個Identity Token就可以被用來登錄客戶端應用程式，而客戶端應用還可以使用Access Token來訪問API資源，UserInfo端點，（OAuth2定義了Authorization端點和Token端點）它允許客戶端應用和獲取用戶的額外資訊，定義了不同型別的應用如何從身份識別提供商（IDP）安全的獲取到這些Token，
與OAuth 2.0之間的角色映射關系
1、身份供應商（Identity Provider，IdP）
2、依賴方（Relying Party，RP，可以理解Wie客戶端）
3、OAuth2里面可以分為兩部分
a、資源所有者/客戶端應用
b、授權服務器/被保護資源
4、身份認證協議里也是兩大不分
a、依賴方
b、身份提供商
5、映射OAuth2------OIDC
授權服務器/被保護資源------身份提供商進行映射
資源所有者--------最終用戶
客戶端應用-----依賴方（RP）
Auth 2.0 與 OIDC 角色映射
抽象流程：
依賴方（RP）發送請求到OpenID提供商（OP，也就是身份提供商），
OpenID提供商驗證最終用戶的身份，并獲得了用戶委派的授權
OpenID提供商回傳回應，里面呆著ID Token，也通常帶著Access Token
依賴方現在可以使用Access Token發送請求到用戶資訊的端點
用戶資訊端點回傳用戶的宣告（claims，相當于是用戶的資訊），
OpenId Connect身份認證流程
Authorization Code Flow：
在Authorization Code流程里，一個授權碼（Authorization Code）會被回傳給客戶端，這個授權碼可以被直接用來交換ID Token和Access Token，該流程也可以在客戶端使用授權碼兌換Access Token之前對其身份認證，但是該流程要求客戶端的身份認證動作在后臺使用Client 和Secret來獲得Tokens，這樣就不會把Tokens暴露給瀏覽器或者其他訪問瀏覽器的惡意應用了，
要求客戶端應用可以安全的在它和授權服務器之間維護客戶端的Secret，也就是說只適合這樣的客戶端應用，它還適合于長時間的訪問（通過Refresh Token），授權碼來自于授權端點，而所有的Tokens都來自于Token端點，
Authorization Code流程的步驟如下：
客戶端準備身份認證請求，請求里包含所需要的引數
客戶端發送請求到授權服務器
授權服務器對最紅用戶進行身份認證
授權服務得最終用戶的統一/授權
授權服務器把最終用戶發送回客戶端，同時帶著授權碼
客戶端使用授權碼向Token端點請求一個回應
客戶端接收到回應，回應的Body里面包含在和ID Token和Access Token
客戶端驗證ID Token，并獲得用戶的一些身份資訊
Implicit Flow：
Implicit在請求Token的時候不需要明確的客戶端身份認證，它使用重定向URI的方式來驗證客戶端的身份，因為這一點，Refresh Token也就無法使用了，這同樣也不適合于長時間有效的Access Token，
所有的Tokens都來自于授權端點，而Token端點并沒有用到，
該流程主要用于瀏覽器內的應用，Access Token和ID To恩一同被直接回傳給客戶端，因為這個原因，這些Tokens也會暴露于最終用戶和跨域訪問該瀏覽器的其他應用了，它并不適合于長時間的訪問，
Implicit流程的步驟如下：
客戶端準備身份認證請求，請求里包含所需要的引數
客戶端發送請求到授權服務器
授權服務器對最終用戶進行身份認證
授權服務器獲得最終用戶的同意/授權
授權服務器把最終用戶發送客戶端，同事帶著ID Token，如果也請求了Access Token的話，那么Access Token也會一同回傳，
客戶端驗證ID Token，并獲得用戶的一些身份資訊，
Hybrid Flow：
Hybrid Flow是前兩者的混合，在該流程里，有一些Tokens和授權碼來自于授權重點，而另外一些Tokens則來自于Token端點，該流程允許客戶端立即使用ID Token，并且只需要一次往返即可獲得授權碼，這種流程也要求客戶端應用可以安全的維護Secret，它也適合于長時間的訪問，
Hybrid Flow的步驟如下：
客戶端準備身份認證請求，請求里包含所需要的引數
客戶端發送請求到授權服務器
授權服務器對最終用戶進行身份認證
授權服務器獲得最終用戶的統一/授權
授權服務器把最終用戶發送回客戶端，同事帶著授權碼，根據回應型別的不同，也考嫩惡搞帶著一個躲著多個其他的引數
客戶端使用授權碼向Token端點請求一個回應
客戶端接收到回應，回應的body里面包含著ID Token和Access Token
客戶端驗證ID Token，并獲得用戶的一些身份資訊，
三種流程特點的比較
回傳值型別的比較
三種型別，根據response_type的不同，分為：
response_type=code id_token、response_type=code token、response_type=code id_token token，
注意：為了表明是OpenID Connect協議的請求，scope引數里必須包含OpenID，
esponse_type=code id_token
response_type=code token
response_type=code id_token token
Identity Server：
建立Identity Provider專案
dentityServer4.Templateshttps://github.com/IdentityServer/IdentityServer4.Templates
安裝工具:
dotnet new -i identityserver4.templates
重置 “dotnet new” 功能串列: dotnet new --debug:reinit
模板:
dotnet new is4empty、 dotnet new is4ui 、dotnet new is4inmem 、dotnet new is4aspid、 dotnet new is4ef 、dotnet new is4admin (收費)
使用Identity Server 建立Authorization Server：https://www.cnblogs.com/cgzl/p/7780559.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/112688.html
標籤：.NET Core
上一篇：[AspNetCore 3.0] 在RazorPages/MVC 中使用 Blazor (Razor組件)
下一篇：ABP入門教程0 - 目錄