Open棟梁Project - マイクロソフト系技術情報 Wiki
(前提知識に、OAuth 2.0 の知識を要する)
外部ログインすると、通常、
OAuth 2.0 の Authorization Server で認証されたユーザのクレームが
Redirectエンドポイントに返るが、これは、OAuth 2.0 自体の仕様ではない。
これは、OAuth 2.0「Authorization Codeグラント種別」の拡張仕様になる。
動作を分析した所、
となっている。
HTTPSのため、仲介コード → Access Tokenの、Responseを確認できず、
OpenID Connectで実装されてる可能性もあると考えたが、
scopeパラメタに「openid」の値を確認できなかったので、OAuth 2.0拡張と思われる。
仲介コード → Access Token → クレームへの変換処理を行っている模様。
この時点で情報は全て、.AspNet?.ExternalCookie?に同梱されるもよう。
(恐らく、クレームなどの情報の露見を防ぐためと思われる)
認証後、遷移元へ遷移した後には、外部ログインの形跡は綺麗に消えている。
以下をライブラリ内で処理することで、セキュリティを高くしている。
だからといって、User-Agentやスマホネイティブで上記に習い、
OAuth 2.0の「Implicitグラント種別」でClientではなく、
User-Agentやスマホネイティブに返したクレームを使ってサーバ認証
・・・というのも意味不明な(認証になって無い)仕様なので、
結局、User-Agentやスマホネイティブでも
外部ログインするしか無い(筈)。
このサーバ間でのユーザー認証の後に
(、OAuthのAccess Tokenで有る必要はなく、別途)、
何らかの認証チケット(的なモノ)を
User-Agentやスマホネイティブに発行することで、
User-Agentやスマホネイティブの認証が可能になる。
なので、この手の(外部ログインによるUser-Agentやスマホネイティブの)
認証方式のポイントは、認証チケット(的なモノの)発行の一般的な方法となる。
Webアプリケーションの認証チケット発行は比較的容易なので、
Hybridなら、Cookie認証チケットを使用して、WebView?内で完結する。
Native & WebAPI間の認証が手薄。
ASP.NET Identityの場合、ここでOAuth Serverのユーザ・ストア無し実装が必要になる。
ASP.NET Identityでの実装を確認した所、ClaimsIdentity?さえ生成できれば、
(多分)ユーザ・ストアが無くてもAccess Tokenを発行可能(だと思う)。
の処理を行なう場合、
// ClaimsIdentityでサインインして、Access Tokenを発行 AuthenticationManager.SignIn(identity);
// 検証完了 context.Validated(identity);
Tags: :認証基盤, :ASP.NET Identity, :OAuth