Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
（前提知識に、OAuth 2.0 の知識を要する）
外部ログインすると、通常、
OAuth 2.0 の Authorization Server で認証されたユーザのClaimが
Redirectエンドポイントに返るが、これは、OAuth 2.0 自体の仕様ではない。
拡張仕様 †
これは、OAuth 2.0「Authorization Codeグラント種別」の拡張仕様になる。
- 通常、OAuth 2.0では、Redirectエンドポイントには、仲介コードが返り、
仲介コードをサーバ側でAccess Tokenに変換した後、Resources Serverへアクセスし、
必要なResources（ここでは認証されたユーザのClaim）を取り出して返すと言う流れになる。
- しかし、外部ログインでは、Redirectエンドポイントに直接、このClaimが返る
（外部ログイン・ライブラリ上で、仲介コード→Claimへの変換処理をしている）。
ASP.NET Identity用のMicrosoftアカウントの外部ログイン・ライブラリの場合 †
動作を分析した所、
- アプリケーションのCallbackのエンドポイントが、
/Account/ExternalLoginCallback?
となっている。
Redirectエンドポイント †
仲介コード→Claimへの変換処理を行っている模様。
- Cookie:
- ASP.NET_SessionId?=XXXXX
- __RequestVerificationToken?=YYYYY
- .AspNet?.Correlation.Microsoft=ZZZZZ1
Callbackのエンドポイント †
この時点で情報は全て、.AspNet?.ExternalCookie?に同梱されるもよう。
（恐らく、Claimなどの情報の露見を防ぐためと思われる）
- 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?)を使用し、遷移後、直ちに削除している。
User-Agentやスマホネイティブでの外部ログインについての考察 †
概要 †
だからといって、User-Agentやスマホネイティブで上記に習い、
OAuth 2.0の「Implicitグラント種別」でClientではなく、
User-Agentやスマホネイティブに返したClaimを使ってサーバ認証
・・・というのも意味不明な（認証になって無い）仕様なので、
結局、User-Agentやスマホネイティブでも
- 「Authorization Codeグラント種別」で
- サーバ（AuthorizationServer?とClient）間で
外部ログインするしか無い（筈）。
ポイント †
このサーバ間でのユーザー認証の後に
（、OAuthのAccess Tokenで有る必要はなく、別途）、
何らかの認証チケット（的なモノ）を
User-Agentやスマホネイティブに発行することで、
User-Agentやスマホネイティブの認証が可能になる。
なので、この手の（外部ログインによるUser-Agentやスマホネイティブの）
認証方式のポイントは、認証チケット（的なモノの）発行の一般的な方法となる。
Hybrid（Webアプリケーション）の場合 †
Webアプリケーションの認証チケット発行は比較的容易なので、
Hybridなら、Cookie認証チケットを使用して、WebView?内で完結する。
Native & WebAPIの場合 †
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);
参考 †
Tags: :認証基盤, :ASP.NET Identity, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
