當我們在登錄一些網站的時候，需要第三方的登錄。比如，現在我們要登錄簡書https://www.jianshu.com/sign_in，我們使用微博登錄，點擊下方的一個微博的小按鈕，就會出現這麼一個地址https://api.weibo.com/oauth2/authorize?client_id=1 ...
當我們在登錄一些網站的時候，需要第三方的登錄。比如，現在我們要登錄簡書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://open.weibo.com/wiki/授權機制，這是微博的授權機制
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html，這是阮一峰老師寫的一篇對於OAuth2的介紹。
OAuth2.0是一個委托協議，它可用讓那些控制資源的人允許某個應用代表這些人，而不是假冒和模仿這喜人，這個應用從資源的所有者哪裡得到授權（Authentication）和Access Token，隨後就可以使用這個Access Token來訪問資源。（這裡提到的假冒和模仿就是指在客戶端複製一份用戶名和密碼，從而獲取響應的許可權）。是關於授權（Authentication）的，客戶端應用可以請求Access Token，使用Tooken就可以訪問API資源了。在上述的例子中，是微博給簡書授權。
讓客戶端應用可以代表資源所有者（通常是用戶）來訪問被保護的資源，如下圖：
資源所有者（Resource Owner），他擁有訪問API資源的許可權，並且他還可以委派許可權（delegate）給其他應用來訪問API。資源所有者通常是可以使用瀏覽器的人。
被保護的資源（Protected Resource）就是資源所有者擁有許可權去訪問的組件，它可以是很多種形式的，但是WebApi的形式還是最常見的。
客戶端（Client）應用就是代表資源所有者訪問被保護資源的一個軟體，註意它既不是瀏覽器，也不是給你錢讓你開發軟體的人，在OAuth2裡面，它是指被保護的API資源的消費者。
授權伺服器（AS）是被受保護的資源所信任的，它可以發行具有特定目的的安全憑據給客戶端應用，這個憑據就叫做OAuth的Access Token。
授權，如下圖
授權種類：
1、Authentication Code
2、Implicit
3、Resource Owner Password Credentials，直接使用密碼憑據（用戶名和密碼）作為授權來獲得Access Token，只有當資源所有者和客戶端之間高度新人的時候並且其它授權方式不可用的時候才可以使用這種授權方式。
4、Client Credentials，有時候，資源或者叫資源伺服器，並不屬於某個最終用戶，也就是沒有資源所有者對該資源負責，但是客戶端應用肯定還是要訪問這些資源，這時候就只能使用Client Credentials這種授權方式了。
其他重要角色和組件：
1、資源所有者Resource Owner
2、客戶端Client
3、被保護資源 Protected Resource
4、授權伺服器Authentication Server
5、Access Token，它是用來訪問被保護資源的憑據，授權伺服器只是方形Token，被保護資源驗證Token，客戶端隊友Access Token應該是完全健忘的。
6、Scopes，被保護資源那裡的一套許可權，具有疊加性
7、Refresh Token，用來獲得Access Token的憑據，客戶端是用Refresh Token來請求信的Access Token
通過refresh token來取得新的access token的流程
重要端點：
1、授權端點（Authentication Endpoint）是用來和資源所有者交互的，資源所有者在這裡進行登錄（身份認證），然後通過該端點可以對客戶端進行授權（Authentication Grant）。授權伺服器首先要驗證資源所有者的身份，但是驗證的方式並不在OAuth2的協議範圍內。
2、Token端點（Token Endpoint），客戶端通過向Token端點展示它的授權（Authorization Grant）或Refresh Token來獲取Access Token。除了Implicit之外所有的授權類型都需要使用該端點，因為Implicit和Access Token是直接發行的。
OpenId Connect（OIDC）
身份認證和授權。OAuth2不是身份認證（Authorization）協議，OpenId Connect可以進行身份認證（Authorization）。
一個比喻，授權，就好比生牛奶（多用途原料）；身份認證，就好比奶茶（一個最終產品），以牛奶為主原料。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
