[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]] -[[戻る>OAuth]] * 目次 [#ba45eec0] #contents *概要 [#nf08aeca] (前提知識に、[[OAuth]] 2.0 の知識を要する) 外部ログインすると、通常、 [[OAuth]] 2.0 の Authorization Server で認証されたユーザのクレームが~ Redirectエンドポイントに返るが、これは、[[OAuth]] 2.0 自体の仕様ではない。 *外部ログイン(認証)の拡張仕様 [#m5ae941c] これは、[[OAuth]] 2.0「Authorization Codeグラント種別」の拡張仕様になる。 -通常、[[OAuth]] 2.0では、Redirectエンドポイントには、仲介コードが返り、~ 仲介コードをサーバ側でAccess Tokenに変換した後、Resources Serverへアクセスし、~ 必要なResources(ここでは認証されたユーザのクレーム)を取り出して返すと言う流れになる。~ -しかし、外部ログインでは、Redirectエンドポイントに直接、このクレームが返る~ (外部ログイン・ライブラリ上で、仲介コード → Access Token → クレームへの変換処理をしている)。 **ASP.NET Identity用のMicrosoftアカウントの外部ログイン・ライブラリの場合 [#jf7626f6] 動作を分析した所、 -実際のRedirectエンドポイントは、~ http://localhost:nnnnn/signin-microsoft -アプリケーションのCallbackのエンドポイントが、~ /Account/ExternalLoginCallback となっている。 HTTPSのため、仲介コード → Access Tokenの、Responseを確認できず、~ [[OpenID Connect]]で実装されてる可能性もあると考えたが、~ scopeパラメタに「openid」の値を確認できなかったので、[[OAuth]] 2.0拡張と思われる。 ***Redirectエンドポイント [#yd211b3f] 仲介コード → Access Token → クレームへの変換処理を行っている模様。 -GET http://localhost:nnnnn/signin-microsoft?code=AAAAA&state=BBBBB HTTP/1.1 -Cookie: --ASP.NET_SessionId=XXXXX --__RequestVerificationToken=YYYYY --.AspNet.Correlation.Microsoft=ZZZZZ1 ***Callbackのエンドポイント [#mc069e8d] この時点で情報は全て、.AspNet.ExternalCookieに同梱されるもよう。~ (恐らく、クレームなどの情報の露見を防ぐためと思われる) -GET http://localhost:nnnnn/Account/ExternalLoginCallback HTTP/1.1 -Cookie: --ASP.NET_SessionId=XXXXX --__RequestVerificationToken=YYYYY --.AspNet.ExternalCookie=ZZZZZ2 ***遷移元への遷移 [#z6e7095a] 認証後、遷移元へ遷移した後には、外部ログインの形跡は綺麗に消えている。 -GET http://localhost:nnnnn/ HTTP/1.1 -Cookie: --ASP.NET_SessionId=XXXXX --__RequestVerificationToken=YYYYY --.AspNet.TwoFactorRememberBrowser=ZZZZZ3 --.AspNet.ApplicationCookie=ZZZZZ4 ***セキュリティに関する考慮点 [#j218c1c3] 以下をライブラリ内で処理することで、セキュリティを高くしている。 -外部ログインを、ライブラリ内部で処理して、 --ユーザの実装ミスによる仲介コード、Access Token等の露見を防いでいる。 --長目のRequestVerificationToken値を使用している。 -Redirectエンドポイント→Callbackのエンドポイント間で、 --仲介コード、Access Token等が露見しないよう、エンドポイントを2段構成にしている。 --エンドポイント間のインターフェイスにCookie(ExternalCookie)を使用し、遷移後、直ちに削除している。 **Bearer Tokenやクレームを[[JWT]]フォーマットに変更する [#yf9cec19] -改竄、置換、CSRF(XSRF)などを検出できる。 -[[JWT#f9d1b3ca]] *User-Agentやスマホネイティブでの外部ログインについての考察 [#y96989f1] **概要 [#q833a0d6] だからといって、User-Agentやスマホネイティブで上記に習い、~ [[OAuth]] 2.0の「Implicitグラント種別」でClientではなく、~ User-Agentやスマホネイティブに返したクレームを使ってサーバ認証~ ・・・というのも意味不明な(認証になって無い)仕様なので、~ 結局、User-Agentやスマホネイティブでも -「Authorization Codeグラント種別」で -サーバ(AuthorizationServerとClient)間で 外部ログインするしか無い(筈)。 **ポイント [#l556d67a] このサーバ間でのユーザー認証の後に~ (、OAuthのAccess Tokenで有る必要はなく、別途)、 何らかの認証チケット(的なモノ)を~ User-Agentやスマホネイティブに発行することで、~ User-Agentやスマホネイティブの認証が可能になる。 なので、この手の(外部ログインによるUser-Agentやスマホネイティブの)~ 認証方式のポイントは、認証チケット(的なモノの)発行の一般的な方法となる。 ***Hybrid(Webアプリケーション)の場合 [#o65b7360] Webアプリケーションの認証チケット発行は比較的容易なので、~ Hybridなら、Cookie認証チケットを使用して、WebView内で完結する。 ***Native & WebAPIの場合 [#l187d128] Native & WebAPI間の認証が手薄。 ASP.NET Identityの場合、ここでOAuth Serverのユーザ・ストア無し実装が必要になる。~ ASP.NET Identityでの実装を確認した所、ClaimsIdentityさえ生成できれば、~ (多分)ユーザ・ストアが無くてもAccess Tokenを発行可能(だと思う)。 -Authorization Code、Implicitグラント種別~ 認可エンドポイントで --Authorization Codeグラント種別(仲介コードの発行) --Implicitグラント種別(Access Tokenの発行) >の処理を行なう場合、 // ClaimsIdentityでサインインして、Access Tokenを発行 AuthenticationManager.SignIn(identity); -Resource Owner Password Credentials、Client Credentialsグラント種別~ TokenエンドポイントでAccess Tokenの発行処理を行なう場合、 // 検証完了 context.Validated(identity); *参考 [#cd0c604f] -[[OAuth]] -[[ASP.NET Identityの外部ログイン]] -[[ASP.NET IdentityによるSTS実装]] --[[ASP.NET IdentityのOAuthによるSTS実装]] ---- Tags: [[:認証基盤]], [[:ASP.NET Identity]], [[:OAuth]]