分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

                                                                                                                       

　隨著軟體的不斷髮展，出現了更多的身份驗證使用場景，除了典型的伺服器與客戶端之間的身份驗證外還有，如服務與服務之間的(如微服務架構)、伺服器與多種客戶端的(如PC、移動、Web等)，甚至還有需要以服務的形式開放給第三方的，身份驗證這一功能已經演化為一個服務，很多大型應用中都有自己的身份驗證伺服器甚至叢集，所以普通的身份驗證方式已經不能滿足需求。

　　在.Net領域中也有一些開源的身份驗證伺服器元件，如IdentityServer(http://identityserver.io/)，但是這些元件對於一些規模較小的專案來說可能會感覺到比較龐大，增加了學習和維護成本，所以本章將對OAuth以及如何使用OAuth實現身份驗證模式進行介紹。
　　本章的主要內容有：

　　● OAuth2.0簡介
 　　● 在.Net中使用OAuth實現基於授權碼模式的身份驗證
 　　● 實現基於Access Token的身份驗證
 　　● 加入Refresh Token支援
 　　● 實現通過使用者密碼模式獲取Access Token
 　　● 實現客戶端模式獲取Access Token
 　　● 關於.Net中OAuth相關令牌的加密說明

　　注：本章內容原始碼下載：https://files.cnblogs.com/files/selimsong/OAuth2Demo.zip

OAuth2.0簡介

　　在文章的開始的時候說過現代軟體應用的身份驗證場景越來越豐富，下圖是現代應用程式的一個通訊圖，它描述了常見的“客戶端”是如何與伺服器提供的服務通訊的。

　　

　　該圖出自IdentityServer：https://identityserver4.readthedocs.io/en/release/intro/big_picture.html
　　為了滿足這些場景人們制定了一套標準協議，這個協議就是OAuth(Open Authorization，開放授權)協議，OAuth能夠讓第三方應用程式去訪問受限制的HTTP服務。OAuth有兩個版本分別是1.0和2.0，但是由於1.0版本過於複雜所以1.0版本被2.0版本替換了，並且兩個版本是不相容的。
　　接下來就對OAuth2.0相關的概念進行介紹：

1. OAuth2.0中的角色

　　● Resource Owner：資源擁有者，就是能夠訪問被限制資源的使用者(注：這裡的使用者是個泛指，它既可以是真實使用者也可以是服務程式)。
 　　● Resource Server：資源宿主，能夠接受和處理，使用訪問令牌(access token)訪問受保護資源的請求（如提供API的伺服器）。
 　　● Client：它泛指所有的第三方程式(無論是Web應用、桌面應用還是服務端應用)，它通過資源擁有者以及它的授權來訪問受保護的資源。
 　　● Authorization Server：用來對授權成功的客戶端釋出令牌以及對令牌的驗證授權。並對Client進行管理。

2.OAuth2.0的協議流程

　　

　　A. 第三方程式向資源擁有者(使用者)傳送授權請求，這個過程既可以通過客戶端直接向用戶請求，也可以通過授權伺服器作為中介來完成請求。（注：對於授權請求這個概念相當於使用者登入，應用程式可以直接顯示一個登入頁面，也可以跳轉到驗證伺服器的統一登入頁面）
　　B. 使用者將授權相關資訊“提交”給第三方程式，在OAuth中有4種不同的許可權授予方式，每種方式需要的資料不同，如基於使用者密碼的授權方式就需要使用者名稱和密碼。
　　C. 第三方程式將使用者的授權資訊提交到授權伺服器，請求一個Access Token。
　　D. 授權伺服器驗證完成使用者的授權資訊後，將Access Token發放到第三方程式。
　　E. 第三方程式攜帶Access Token訪問被保護的資源。
　　F. 資源伺服器驗證Access Token有效後，將資源返回到第三方程式。

3. OAuth中的授權模式(即獲取Access Token的方式)

　　● Authorization Code(授權碼模式)：該模式的核心是客戶端通過一個授權碼來向授權伺服器申請Access Token。是一種基於重定向的授權模式，授權伺服器作為使用者和第三方應用(Client)的中介，當用戶訪問第三方應用是，第三方應用跳轉到授權伺服器引導使用者完成身份驗證，生成Authorization Code並轉交到第三方應用，以便於第三方應用根據這個授權碼完成後續的Access Token獲取。
 　　● Implicit（簡化模式）：簡化模式是一種簡化的授權碼模式，授權碼模式在首次訪問第三方應用時跳轉到授權伺服器進行身份驗證返回授權碼，而簡化模式在跳轉到授權伺服器後直接返回Access Token，這種模式減少了獲取Access Token的請求次數。
 　　● Resource Owner Password Credentials（使用者密碼模式）：通過資源擁有者(使用者)的使用者名稱和密碼來直接獲取Access Token的一種方法，這種方法要求第三方應用(Client)是高度可信任的，並且其它授權方式不可用的情況下使用。
 　　● Client Credentials（客戶端模式）：該模式是通過第三方應用(Client)傳送一個自己的憑證到授權伺服器獲得Access Token，這種模式的使用要求該Client已經被授權伺服器管理並限制其對被保護資源的訪問範圍。另外這種模式下Client應該就是一個資源擁有者(使用者)，如微服務程式。

4. Access Token & Refresh Token

　　這個很好理解，第三方應用通過Access Token去獲取受保護的資源，但是Access Token是存在有效期的，一旦過期就無法使用，為了避免Access Token過期後無法使用，所以加入了Refresh Token的概念，通過重新整理的方式來完成Access Token的更新。

5. Client的註冊

　　在OAuth2.0中，所有需要訪問受限資源的程式都視為第三方應用（Client），為了保證這個Client是安全的、可信任的，所以OAuth需要對Client進行管理。參考：https://tools.ietf.org/html/rfc6749#section-2

6. OAuth的終結點

　　這裡終結點代表的是HTTP資源，在OAuth授權過程中需要使用到一些終結點的支援，如Authorization code（授權碼）的獲取，以及Access Token的獲取，終結點由授權伺服器提供。參考：https://tools.ietf.org/html/rfc6749#section-3

7. Access Token Type

　　Access Token的型別是讓Client根據具體型別來使用Access Token完成對受保護資源的請求。
　　OAuth2.0中有兩種型別分別是Bearer和Mac，它們體現方式如下：
　　 ● Bearer：

　　

　　  ● Mac：

　　

　　參考：https://tools.ietf.org/html/rfc6750

在.Net中使用OAuth實現基於授權碼模式的身份驗證

　　OAuth2.0是一個開放標準，既然是標準那麼就可以有實現，在.Net中微軟基於Owin實現了OAuth2.0協議，下面就介紹如何在ASP.NET MVC程式中實現OAuth身份驗證。
　　注：本例基於ASP.NET MVC預設帶身份驗證模板完成。

1. 元件安裝

　　通過NuGet安裝Microsoft.Owin.Security.OAuth元件：

　　

　　注：從該元件的名稱可以看出，.Net對OAuth的實現實際上是基於Owin的，所以很多內容均使用Owin中相關的身份驗證概念，這些內容可參考本系列與身份驗證的文章。

2. 新增OAuth授權伺服器

　　根據上面OAuth的介紹可知，授權伺服器是OAuth其中一個角色，該角色最主要的功能就是Access Token的發放以及授權，另外它還用於支援授權碼模式的授權碼發放以及Client的管理。
　　在Startup型別的Configuration方法中加入以下程式碼，該程式碼是為Owin中介軟體新增一個授權伺服器（注：該中介軟體是一個Owin的身份驗證中介軟體可參考《ASP.NET沒有魔法——ASP.NET Identity 的“多重”身份驗證》）。

　　

　　其中OAuthAuthorizationServerOptions定義如下：

　　

　　上面的定義可以分為以下幾類：
 　　● 終結點地址：AuthorizeEndpointPath、TokenEndpointPath等，它定義了訪問獲取授權碼以及獲取Token的地址資訊。
 　　● Token提供器：AuthorizationCodeProvider、AccessTokenProvider、RefreshTokenProvider負責完成對應令牌的建立和處理功能。
 　　● Token的“加密”與“解密”：該功能是OAuth與Owin身份驗證的結合，通過AccessTokenFormat等ISecureDataFormat介面的實現可以將對應的Token轉換成一個　　AuthenticationTicket。可參考《ASP.NET沒有魔法——ASP.NET Identity的加密與解密》文中TicketDataFormat的用法。
 　　● OAuth授權服務：Provider是整個OAuth伺服器的核心，它包含了終結點的處理與響應、OAuth中的4種Access Token授權方式和重新整理令牌獲取Access Token的方式以及請求、客戶端的相關驗證：

　　

3. 為授權伺服器新增終結點

　　上面介紹OAuth時介紹了終結點實際上就是用來獲取授權碼或者Access Token的，在.Net中使用Microsoft.Owin.Security.OAuth元件僅需要通過配置的形式就可以指定授權碼及Token獲取的終結點訪問地址(注：把AllowInsecureHttp配置屬性設為true，可以允許不安全的http來訪問終結點，該配置僅用於開發環境)：

　　

　　完成後就可以通過瀏覽器訪問這兩個地址：

　　

　　

　　可以看到是可以訪問，只不過是有錯誤的（注：請求地址的QueryString的引數參考文件）。

4. Client的管理與驗證

 　　Client在OAuth中指代了所有的第三方需要訪問受限制資源的應用程式，授權伺服器為了能夠識別和驗證Client所以需要完成Client的管理以及驗證功能。（注：微軟在Microsoft.Owin.Security.OAuth元件中僅僅提供了Client驗證的介面，所以要自己實現Client資料的管理以及驗證邏輯）：

　　1). 新增Client實體以及對應的倉儲(本例以記憶體的方式實現倉儲，實際使用中至少應該儲存資料庫)：

　　

　　上圖是Client最基礎的屬性（注：如果還需要對Client的訪問範圍進行限制，那麼還應該加入一個Scope的列表，本例不再加入Scope的限制）。

　　2). Client的倉儲：

　　

　　3). 實現授權伺服器對Client的驗證：

　　由於授權伺服器對客戶端驗證的介面位於OAuthAuthorizationServerProvider型別中，所以首先要繼承該型別，並重載相應的驗證方法：

　　

　　上面程式碼做了以下幾件事：
 　　● 嘗試從Http請求header或者請求body中獲取Client資訊，包含Id和密碼。
 　　● 如果沒有Client的Id資訊，那麼直接判斷為不通過驗證，如果有Client的密碼資訊則儲存到Owin上下文中，供後續處理使用。
 　　● 使用獲得的ClientId在Client倉儲中查詢，判斷是否是一個合法的Client，如不是則判斷為不通過驗證。

　　4). 驗證完成後設定該Client的重定向Url(注：該方法仍舊是過載OAuthAuthorizationServerProvider型別中的方法)：

　　

5. 新增授權碼提供器

　　授權碼的生成是授權伺服器終結點的一項功能，當使用授權碼模式時，使用者訪問Client會被引導跳轉到授權伺服器完成身份驗證(登入)，隨後又攜帶授權碼跳轉回Client，Client使用該授權碼獲取Access Token。在OAuth的.Net實現中，需要通過在配置中配置一個型別為IAuthenticationTokenProvider的令牌提供器，該提供器用於建立和解析令牌，這裡的建立實際就是使用者完成登入後授權碼的生成以及授權碼和使用者登入身份資訊的關聯，而解析實際就是根據授權碼獲得對應使用者身份資訊並生成Access Token的過程。

　　下面就通過實現IAuthenticationTokenProvider的方式實現一個自定義授權碼提供器：

　　

　　從上面程式碼可以看出這個提供器的核心功能是以Guid的方式生成一個鍵值(授權碼)儲存了當前使用者的資訊，當解析時通過該鍵值(即授權碼)獲取使用者身份資訊。(注：AuthenticationTokenCreateContext物件用於對當前使用者身份資訊AuthenticationTicket對的的序列化和反序列化)

　　完成後將該提供器配置到授權伺服器中介軟體中：

　　

6. 為授權伺服器新增使用者授權提示頁面

　　當用戶訪問授權碼終結點時理應讓使用者知道Client需要他的授權，為此在ASP.NET MVC程式中需要新增一個路由與授權碼終結點地址匹配的Controller、Action以及View：

　　1). Controller及Action(注：該Action需要通過身份驗證，如果沒有需要跳轉到登入頁面完成身份驗證後才可訪問)：

　　

　　2). View：顯示授權提示

　　

7. 執行程式

　　1). 訪問授權碼終結點獲取授權碼：http://localhost:59273/oauth2/authorize?response_type=code&client_id=test1

　　由於沒有登入，所以先跳轉到登入頁面。

　　

　　完成登入後跳轉回授權頁面：

　　

　　點選授權按鈕後，攜帶授權碼跳轉到test1這個client的重定向Url(注：此處test1這個Client設定的Url就是授權伺服器本身，所以看上去沒有做重定向)

　　

　　得到授權碼後，攜帶授權碼訪問Access Token終結點獲取Access Token(注：這裡使用Chrome瀏覽器的Postman拓展來實現請求的模擬)：

　　

　　注：上面響應資訊中的access_token包含了加密後用戶的身份資訊，其加密過程可參考基於Cookie的使用者資訊加密過程。ASP.NET沒有魔法——ASP.NET Identity的加密與解密

實現基於Access Token的身份驗證

　　上面介紹瞭如何基於授權碼模式獲得Access Token，接下來將介紹如何使用Access Token來訪問受限制的資源(注：本例中的資源伺服器與授權伺服器位於同一例項中，所以當資源伺服器對access token解密時，能夠保證與授權伺服器用於生成access token所用金鑰一致，能夠正常解密，這裡的Access Token和基於Cookie的身份驗證中的身份驗證Cookie性質是相同的，都是將使用者的身份資訊序列化後的加密字串)

　　1. 在Startup類中新增基於Bearer的OAuth身份驗證中介軟體：

　　

　　2. 新增訪問受限制的資源：

　　

　　3. 訪問受限資源：

　　未新增授權資訊直接跳轉到登入頁面。

　　

　　新增Access Token後可正常訪問資源：

　　

加入Refresh Token支援

　　上面使用授權碼模式生成的Access Token是存在過期時間的(實際上無論什麼方式生成的Access Token都存在過期時間)，Token過期後又不可能讓使用者再授權一次，所以需要使用Refresh Token來定期重新整理Access Token，.Net中實現Refresh Token的方式與授權碼類似，在生成Refresh Token的同時會關聯使用者的身份資訊，後續可以使用這個Refresh Token來生成新的Access Token。

　　1. 建立Refresh Token提供器(實現方式與授權碼提供器基本一致)：

　　

 　　2. 為授權伺服器配置Refresh Token提供器：

　　

　　3. 再次獲取到授權碼後，根據該授權碼獲取Access Token，返回資訊中將攜帶Refresh Token：

　　

　　4. 根據Refresh Token重新整理Access Token：

　　

實現通過使用者密碼模式獲取Access Token

　　上面介紹了授權碼模式的實現方式，但這種方式的核心實際上是建立了一個授權碼和使用者資訊的對映(包括重新整理令牌方式也是建立了重新整理令牌與使用者資訊的對映)，後續的Access Token實際上是使用這個了使用者資訊生成的。換句話使用者資訊才是核心，.Net中使用者資訊的體現從底到高分別是：IIdentity->ClaimsIdentity-> AuthenticationTicket，關於使用者的身份資訊可參考：《ASP.NET沒有魔法——ASP.NET Identity與授權》，在基於授權碼的模式時通過在授權伺服器的登入功能獲得了使用者資訊，而基於使用者名稱密碼模式時沒有這個跳轉登入環節，所以需要直接通過使用者名稱密碼來獲取使用者資訊，其實現如下過載了OAuthAuthorizationServerProvider型別的GrantResourceOwnerCredentials方法：

　　

　　該方法從Owin環境中獲取Identity中的UserManager物件，通過UserManager來驗證使用者是否存在，如果存在則將使用使用者資訊來建立一個ClaimsIdentity物件(注：此處是省略的實現，正常實現可根據需求參考Cookie驗證方式將Scope或者Role等資訊也新增到Identity物件中)。另UserManager是通過以下程式碼新增到Owin上下文中的，它的Key值是"AspNet.Identity.Owin:" + typeof(ApplicationUserManager).AssemblyQualifiedName。

　　

　　使用使用者名稱密碼獲取Access Token：

　　

實現客戶端模式獲取Access Token

　　客戶端模式和使用者名稱密碼模式是類似的，它是通過Client的Id以及密碼來進行授權，使用的是Client相關的資訊，它的實現方式如下，過載GrantClientCredentials方法，通過客戶端驗證後的id和密碼資訊來驗證改Client是否合法，對於合法的Client為其建立Identity物件(注：此處可以根據實際需求在Identity中新增相應的屬性)：

　　

　　使用Client資訊獲取Access Token：

　　

　　以上就是.Net中對於OAuth的實現，另外.Net中沒有提供簡化模式的介面，但是提供了一個GrantCustomExtension，也就是說授權模式是可拓展的。

關於.Net中OAuth相關令牌的加密說明

　　本例中除了授權碼以及重新整理令牌是2個Guid連線外，訪問令牌(包括所有授權模式生成的令牌)以及授權碼對應的使用者資訊、重新整理令牌對應的使用者資訊都是經過加密的，其加解密物件建立過程如下，具體內容可參考《ASP.NET沒有魔法——ASP.NET Identity的加密與解密》

　　

小結

　　本章內容介紹了OAuth2.0協議相關的內容，並通過一個ASP.NET MVC程式基於微軟的Microsoft.Owin.Security.OAuth元件實現了該協議中的大部分功能。使用OAuth來實現身份驗證可以讓我們的應用程式從Web拓展至任意的平臺上執行，但這樣的實現仍舊是存在一些問題的，在下一篇文章中將對這些問題進一步的討論和介紹。

PS.這一章內容比較多，如有問題可以在評論區留言，另外最近事情比較多，所以更新慢了，感謝大家的支援。

參考：

　　https://stackoverflow.com/questions/39909419/jwt-vs-oauth-authentication
　　http://www.cnblogs.com/linianhui/p/oauth2-authorization.html
　　http://www.c-sharpcorner.com/UploadFile/4b0136/openid-connect-availability-in-owin-security-components/
　　https://docs.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
　　https://security.stackexchange.com/questions/94995/oauth-2-vs-openid-connect-to-secure-api
　　http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/

原文：http://www.cnblogs.com/selimsong/p/8037717.html 

.NET社群新聞，深度好文，歡迎訪問公眾號文章彙總 http://www.csharpkit.com

                             

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow