- 追加された行はこの色です。
- 削除された行はこの色です。
[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]
-[[戻る>OAuth]]
* 目次 [#ba45eec0]
#contents
*概要 [#nf08aeca]
（前提知識に、[[OAuth]] 2.0 の知識を要する）
外部ログインすると、通常、
[[OAuth]] 2.0 の Authorization Server で認証されたユーザのClaimが~
Redirectエンドポイントに返るが、これは、[[OAuth]] 2.0 自体の仕様ではない。
*拡張仕様 [#m5ae941c]
これは、[[OAuth]] 2.0「Authorization Codeグラント種別」の拡張仕様になる。
-通常、[[OAuth]] 2.0では、Redirectエンドポイントには、仲介コードが返り、~
仲介コードをサーバ側でAccess Tokenに変換した後、Resources Serverへアクセスし、~
必要なResources（ここでは認証されたユーザのClaim）を取り出して返すと言う流れになる。~
-しかし、外部ログインでは、Redirectエンドポイントに直接、このClaimが返る~
（外部ログイン・ライブラリ上で、仲介コード→Claimへの変換処理をしている）。
（外部ログイン・ライブラリ上で、仲介コード → Access Token → Claimへの変換処理をしている）。
**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]
仲介コード→Claimへの変換処理を行っている模様。
仲介コード → Access Token → Claimへの変換処理を行っている模様。
-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に同梱されるもよう。~
（恐らく、Claimなどの情報の露見を防ぐためと思われる）
-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)を使用し、遷移後、直ちに削除している。
*User-Agentやスマホネイティブでの外部ログインについての考察 [#y96989f1]
**概要 [#q833a0d6]
だからといって、User-Agentやスマホネイティブで上記に習い、~
[[OAuth]] 2.0の「Implicitグラント種別」でClientではなく、~
User-Agentやスマホネイティブに返したClaimを使ってサーバ認証~
・・・というのも意味不明な（認証になって無い）仕様なので、~
結局、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]]
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
