- 追加された行はこの色です。
- 削除された行はこの色です。
[[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への変換処理をしている)。
**Microsoftアカウントの外部ログイン・ライブラリの場合 [#jf7626f6]
-実際のRedirectエンドポイントは、~
http://localhost:nnnnn/signin-microsoft
-アプリケーションのCallbackのエンドポイントが、~
/Account/ExternalLoginCallback
となっている。
***Redirectエンドポイント [#yd211b3f]
仲介コード→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
*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実装]]