Asp.net 的Security框架除了提供Cookies,OAuth,ActiveDirectory等多個用戶認證實現，基本上已經滿足業務項目的開發需要了。

當需要實現OAuth2.0服務器端實現的時候第一想法可能是使用IdentityServer3或者4，其實在Security框架中也提供了這樣一個簡易實現，可以滿足我們的需求了，而且代碼更加的簡潔。在web項目中引入相關nuget包並運行起來，一臺OAuth2.0 Server就跑起來了。

核心類就是OAuthAuthorizationServerHandler，總體設計思路就是在該類型中會先判定請求是希望獲取AuthorizationCode（這裏只討論授權碼模式）還是AccessToken從而執行不同的流程，如果是獲取AccessToken的話會判定client_id和redirect_uri正確時候就會返回相應的結果。框架為我們提供了OAuthAuthorizationServerOptions選項參數來配置OAuth2.0.後面所有提到的Options都指該類型。

OAuth2.0在各種操作中會需要傳遞相應的參數，比如client_id,redirect_uri,response_type之類，框架為我們提供了AuthorizeEndpointRequest類型方便我們根據IOwinRequest提取保存在QueryString裏的臨時碼接口參數，TokenEndpointRequest類型方便我們提取保存在請求Body裏的AccessToken接口參數，一切都顯得簡潔緊湊，避免了一鍋粥似得淩亂代碼。

1.在請求到來的時候會首先判斷請求是否希望獲取AuthorizationCode或者AccessToken，如果都不是的話Request請求就不會執行OAuth2.0的代碼邏輯。我們可以在OAuthAuthorizationServerOptions配置項的如下兩個屬性中設置相應的屬性。同時框架也為我們提供了一個擴展--Options的MatchesTokenEndpoint來自定義邏輯判斷當前請求是否符合OAuth2.0 api接口路徑。（我們還可以配置是否只接受https安全連接）

2.如果判斷是AuthorizationCode請求的話（默認就是/authorize請求路徑），接著確定請求Uri為合法的請求路徑，同樣的Options參數中也可以設置一些自定義的驗證代碼，如果一切執行ok，此時我們就需要為Options的Provider屬性的OnAuthorizeEndpoint提供如下的一個委托函數，如果我來實現這個OAuth2.0 Server的話，我會在下圖的這個委托方法中生成一個隨機的code字符串，連同請求Request的state參數（如果有的話）以QueryString參數的形式設置到redirect_uri上，並執行該redirect_uri。這樣就能將臨時code傳遞給Application 服務器了。Application服務器獲取到該臨時code連同其他OAuth2.0規範的參數就可以訪問我們的OAuth2.0 Server的AccessToken請求接口了。該AccessToken的Api接口如步驟3。

3.AccessToken接口通常是Application Server在獲取到臨時Code，帶上符合OAuth2.0規範的參數然後發起調用的。如果判斷是AccessToken請求的話（默認就是/token請求路徑），或許我們需要判定一下請求所攜帶的client_id和Client_secret是否正確，為了做到這一點，我們需要配置Options的Provider.OnValidateClientAuthentication來進行驗證。

如果一切順利，下面就要生成AccessToken了，框架中生成的AccessToken其實就一個身份信息AuthenticationTicket處理之後生成的一個字符串。如下圖所示的Options.AuthorizationCodeProvider.ReceiveAsync(authorizationCodeContext)代碼中產生

另外需要註意的是默認產生的AccessToken只有20分鐘左右的有效期，這個有效期是必須存在的，我們可以通過配置Options.AccessTokenExpireTimeSpan來配置的長久一些，為了能刷新這個AccessToken必須在其過期之前調用刷新接口。

如果一切執行順利將會返回如下所示的一個Json字符串

（純粹是為了下個月找工作而準備的一系列博文，每一篇都盡量精簡，並非給初學者看的?）

Asp.net Security框架（2）