「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 外部ログイン（認証）の仕様の調査。
- 前提知識に、OAuth 2.0 の知識を要する。
外部ログイン（認証）の仕様 †
これは、OAuth 2.0「Authorization Codeグラント種別」の拡張仕様になる。
- 通常、OAuth 2.0では、Redirectエンドポイントには、仲介コードが返り、
仲介コードをサーバ側でAccess Tokenに変換した後、Resources Serverへアクセスし、
必要なResources（ここでは認証されたユーザのクレーム）を取り出して返すと言う流れになる。
- しかし、外部ログインでは、Redirectエンドポイントに直接、このクレームが返る
（外部ログイン・ライブラリ上で、仲介コード → Access Token → クレームへの変換処理をしている）。
ASP.NET Identity用のMicrosoftアカウントの外部ログイン・ライブラリの場合 †
動作を分析した所、
- アプリケーションのCallbackのエンドポイントが、
/Account/ExternalLoginCallback?
となっている。
HTTPSのため、仲介コード → Access Tokenの、Responseを確認できず、
OpenID Connectで実装されてる可能性もあると考えたが、
scopeパラメタに「openid」の値を確認できなかったので、OAuth 2.0拡張と思われる。
Redirectエンドポイント †
仲介コード → Access Token → クレームへの変換処理を行っている模様。
- Cookie:
- ASP.NET_SessionId?=XXXXX
- __RequestVerificationToken?=YYYYY
- .AspNet?.Correlation.Microsoft=ZZZZZ1
Callbackのエンドポイント †
この時点で情報は全て、.AspNet?.ExternalCookie?に同梱されるもよう。
（恐らく、クレームなどの情報の露見を防ぐためと思われる）
- Cookie:
- ASP.NET_SessionId?=XXXXX
- __RequestVerificationToken?=YYYYY
- .AspNet?.ExternalCookie?=ZZZZZ2
遷移元への遷移 †
認証後、遷移元へ遷移した後には、外部ログインの形跡は綺麗に消えている。
- Cookie:
- ASP.NET_SessionId?=XXXXX
- __RequestVerificationToken?=YYYYY
- .AspNet?.TwoFactorRememberBrowser?=ZZZZZ3
- .AspNet?.ApplicationCookie?=ZZZZZ4
セキュリティに関する考慮点 †
以下をライブラリ内で処理することで、セキュリティを高くしている。
- 外部ログインを、ライブラリ内部で処理して、
- ユーザの実装ミスによる仲介コード、Access Token等の露見を防いでいる。
- 長目のRequestVerificationToken?値を使用している。
- Redirectエンドポイント→Callbackのエンドポイント間で、
- 仲介コード、Access Token等が露見しないよう、エンドポイントを2段構成にしている。
- エンドポイント間のインターフェイスにCookie(ExternalCookie?)を使用し、遷移後、直ちに削除している。
外部ログイン（認証）の拡張仕様 †
主に、以下のようなセキュリティ上の問題への対応
によって拡張された仕様（認証に関わらずだけど）。
Proof Key for Code Exchange by OAuth Public Clients †
概要 †
Authorization Codeグラント種別により発行された認可コードをクライアントアプリケーションが受け取る際、
悪意のあるアプリケーションがその認可コードを横取りするという、
「認可コード横取り攻撃」(authorization code interception attack)に対抗する仕様。
- 認可エンドポイント
| # | パラメタ | 要否 | 説明 |
| 1 | code_challenge | 必須 | Code Verifier を元に計算された Code Challenge の値 |
| 2 | code_challenge_method | 任意 | Code Challenge の計算に用いるメソッド。plain (デフォルト) もしくは S256。 |
- Tokenエンドポイント
| # | パラメタ | 要否 | 説明 |
| 1 | code_verifier | 必須 | Code Challenge の元となった Code Verifier の値 |
参考 †
OAuth 2.0 Multiple Response Type Encoding Practices †
code token（Hybrid Flow）などの、新しいresponse_typeが追加されている。
（これにより、Token置換攻撃を防ぐなど、安全性を高めている模様）
参考 †
OAuth2.0 Proof of Possession †
参考 †
こちら。
Bearer TokenやクレームをJWTアサーションに変更する †
Tokenやクレームに、JWTアサーションを使用すれば、改竄、置換、CSRF（XSRF）などを検出することができる。
- OAuth 2.0ではアクセストークンまで仕様化されていないのでJWTアサーションを利用可能。
- アクセストークンに、JWTアサーションを使用すれば、改竄、置換、CSRF（XSRF）等に耐える為、Implicitグラント種別でも安全性が高くなる。
参考 †
User-Agentやスマホネイティブでの外部ログインについての考察 †
課題 †
問題は、
- クライアント（User-Agentやスマホネイティブ）という改竄、置換などの攻撃を行う可能性のある"仲介者"が存在する中、
- 「Implicitグラント種別」（アクセストークンをHTTPでサイト間を経由しクライアントに渡す）を使用して、
サーバ間でSSO認証をする必要があること。
解決 †
結局、User-Agentやスマホネイティブでも
- 「Authorization Codeグラント種別」で
- サーバ（Authorization ServerとClient）間で
外部ログインするしか無いのか？
→ code token（Hybrid Flow）などの、新しいresponse_typeが追加された。
→ 認証チケットに改竄検知の署名を追加するためJWTアサーションを使用。
参考 †
- ASP.NET IdentityのOAuthによるSTS実装?
Tags: :認証基盤, :ASP.NET Identity, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
