![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>OAuth]] * 目次 [#ba45eec0] #contents *概要 [#nf08aeca] -外部ログイン（認証）の仕様の調査。 -前提知識に、[[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)を使用し、遷移後、直ちに削除している。 *外部ログイン（認証）の拡張仕様 [#b5093a27] 主に、以下のようなセキュリティ上の問題への対応~ によって拡張された仕様（認証に関わらずだけど）。 -HTTPS でも Full URL が漏れる？OAuth の code も漏れるんじゃね？？ - OAuth.jp~ http://oauth.jp/blog/2016/07/27/https-full-url-leaks/ **Proof Key for Code Exchange by OAuth Public Clients [#k2c8dd16] ***概要 [#f3afd920] Authorization Codeグラント種別により発行された認可コードをクライアントアプリケーションが受け取る際、~ 悪意のあるアプリケーションがその認可コードを横取りするという、~ 「認可コード横取り攻撃」(authorization code interception attack)に対抗する仕様。 -[[各エンドポイント>OAuth#h4dcb0c7]]で受け取るパラメタ --認可エンドポイント |#|パラメタ|要否|説明|h |1|code_challenge|必須|Code Verifier を元に計算された Code Challenge の値| |2|code_challenge_method|任意|Code Challenge の計算に用いるメソッド。plain (デフォルト) もしくは S256。| --Tokenエンドポイント |#|パラメタ|要否|説明|h |1|code_verifier|必須| Code Challenge の元となった Code Verifier の値| ***参考 [#xd12c523] -RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients~ https://tools.ietf.org/html/rfc7636 -その他 --PKCE: 認可コード横取り攻撃対策のために OAuth サーバーとクライアントが実装すべきこと - Qiita~ http://qiita.com/TakahikoKawasaki/items/00f333c72ed96c4da659 **OAuth 2.0 Multiple Response Type Encoding Practices [#oae281fb] code token（Hybrid Flow）などの、新しいresponse_typeが追加されている。~ （これにより、Token置換攻撃を防ぐなど、安全性を高めている模様） ***参考 [#le235a51] -Final: OAuth 2.0 Multiple Response Type Encoding Practices~ http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html -その他 --GoogleのOAuth 2.0実装におけるToken置換攻撃の防ぎ方 - r-weblife~ http://d.hatena.ne.jp/ritou/20120702/1341235859 --OAuth 2.0 の Response Type 全パターン - OAuth.jp~ http://oauth.jp/blog/2015/01/06/oauth2-multiple-response-type/ **OAuth2.0 Proof of Possession [#lb688774] ***参考 [#db92b661] [[こちら>JWTとOAuth2.0#u8ebfddc]]。 **Bearer Tokenやクレームを[[JWT]]アサーションに変更する [#yf9cec19] Tokenやクレームに、[[JWT]]アサーションを使用すれば、改竄、置換、CSRF（XSRF）などを検出することができる。 -[[OAuth]] 2.0ではアクセストークンまで仕様化されていないので[[JWT]]アサーションを利用可能。 -アクセストークンに、[[JWT]]アサーションを使用すれば、改竄、置換、CSRF（XSRF）等に耐える為、Implicitグラント種別でも安全性が高くなる。 -[[OpenID Connect]]の[[IDトークン>OpenID Connect#ofb73c59]]を参考にして、[[JWT]]アサーションを発行し、これを検証すれば、認証用途に利用できる。 ***参考 [#g5c32594] -[[ASP.NET Identity]]でアクセストークンを[[JWT]]アサーションに変更できるもよう。 --詳しくは、[[コチラ>ASP.NET IdentityのOAuthによるSTS実装#a0f5b8a7]]を参照。 -モバイルアプリのユーザ認証方法についてまとめてみた - Qiita~ http://qiita.com/ledmonster/items/0ee1e757af231aa927b1 --10 Things You Should Know about Tokens~ 9. JSON Web Tokens can be used in OAuth: Bearer Token~ https://auth0.com/blog/ten-things-you-should-know-about-tokens-and-cookies/#token-oauth *User-Agentやスマホネイティブでの外部ログインについての考察 [#y96989f1] **課題 [#y4777e16] 問題は、 -クライアント（User-Agentやスマホネイティブ）という改竄、置換などの攻撃を行う可能性のある"仲介者"が存在する中、 -「Implicitグラント種別」（アクセストークンをHTTPでサイト間を経由しクライアントに渡す）を使用して、 サーバ間でSSO認証をする必要があること。 **解決 [#z2e54cac] ***[[OAuth 2.0 Multiple Response Type Encoding Practices>#oae281fb]] [#u8f6ae88] 結局、User-Agentやスマホネイティブでも -「Authorization Codeグラント種別」で -サーバ（Authorization ServerとClient）間で 外部ログインするしか無いのか？ → code token（Hybrid Flow）などの、新しいresponse_typeが追加された。 ***[[OAuth2.0 Proof of Possession>#lb688774]] [#sd175d92] ***[[Bearer TokenやクレームをJWTアサーションに変更する>#yf9cec19]] [#d566930b] → 認証チケットに改竄検知の署名を追加するため[[JWT]]アサーションを使用。 *参考 [#cd0c604f] **[[WebAPIの認証]] [#h9195579] **[[OAuth]] [#nb690fce] ***[[JWTとOAuth2.0]] [#z7f010e7] **[[ASP.NET Identity]] [#nf0fd670] ***[[ASP.NET Identityの外部ログイン]] [#pc0bbd22] ***[[ASP.NET IdentityによるSTS実装]] [#j471d437] -[[ASP.NET IdentityのOAuthによるSTS実装]] ---- Tags: [[:認証基盤]], [[:ASP.NET Identity]], [[:OAuth]]
