標籤:server 左右 調用 避免 多個 and stat option 伺服器
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)