OAuthによる外部ログインの研究 のバックアップ(No.7)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• ソース を表示
• OAuthによる外部ログインの研究 は削除されています。
  • 1 (2017-01-04 (水) 10:04:15)
  • 2 (2017-01-04 (水) 13:52:20)
  • 3 (2017-01-04 (水) 15:38:12)
  • 4 (2017-01-04 (水) 19:09:42)
  • 5 (2017-01-06 (金) 21:36:58)
  • 6 (2017-01-06 (金) 23:31:38)
  • 7 (2017-01-07 (土) 14:49:37)

---

Open棟梁Project - マイクロソフト系技術情報 Wiki

• 戻る

目次 †

概要 †

（前提知識に、OAuth 2.0 の知識を要する）

外部ログインすると、通常、

OAuth 2.0 の Authorization Server で認証されたユーザのクレームが
Redirectエンドポイントに返るが、これは、OAuth 2.0 自体の仕様ではない。

外部ログイン（認証）の拡張仕様 †

これは、OAuth 2.0「Authorization Codeグラント種別」の拡張仕様になる。

• 通常、OAuth 2.0では、Redirectエンドポイントには、仲介コードが返り、
  仲介コードをサーバ側でAccess Tokenに変換した後、Resources Serverへアクセスし、
  必要なResources（ここでは認証されたユーザのクレーム）を取り出して返すと言う流れになる。
  

• しかし、外部ログインでは、Redirectエンドポイントに直接、このクレームが返る
  （外部ログイン・ライブラリ上で、仲介コード → Access Token → クレームへの変換処理をしている）。

ASP.NET Identity用のMicrosoftアカウントの外部ログイン・ライブラリの場合 †

動作を分析した所、

• 実際のRedirectエンドポイントは、
  http://localhost:nnnnn/signin-microsoft

• アプリケーションのCallbackのエンドポイントが、
  /Account/ExternalLoginCallback?

となっている。

HTTPSのため、仲介コード → Access Tokenの、Responseを確認できず、
OpenID Connectで実装されてる可能性もあると考えたが、
scopeパラメタに「openid」の値を確認できなかったので、OAuth 2.0拡張と思われる。

Redirectエンドポイント †

仲介コード → Access Token → クレームへの変換処理を行っている模様。

• 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のエンドポイント †

この時点で情報は全て、.AspNet?.ExternalCookie?に同梱されるもよう。
（恐らく、クレームなどの情報の露見を防ぐためと思われる）

• GET http://localhost:nnnnn/Account/ExternalLoginCallback HTTP/1.1

• Cookie:
  • ASP.NET_SessionId?=XXXXX
  • __RequestVerificationToken?=YYYYY
  • .AspNet?.ExternalCookie?=ZZZZZ2

遷移元への遷移 †

認証後、遷移元へ遷移した後には、外部ログインの形跡は綺麗に消えている。

• GET http://localhost:nnnnn/ HTTP/1.1

• Cookie:
  • ASP.NET_SessionId?=XXXXX
  • __RequestVerificationToken?=YYYYY
  • .AspNet?.TwoFactorRememberBrowser?=ZZZZZ3
  • .AspNet?.ApplicationCookie?=ZZZZZ4

セキュリティに関する考慮点 †

以下をライブラリ内で処理することで、セキュリティを高くしている。

• 外部ログインを、ライブラリ内部で処理して、
  • ユーザの実装ミスによる仲介コード、Access Token等の露見を防いでいる。
  • 長目のRequestVerificationToken?値を使用している。

• Redirectエンドポイント→Callbackのエンドポイント間で、
  • 仲介コード、Access Token等が露見しないよう、エンドポイントを2段構成にしている。
  • エンドポイント間のインターフェイスにCookie(ExternalCookie?)を使用し、遷移後、直ちに削除している。

Bearer TokenやクレームをJWTフォーマットに変更する †

• これにより、Bearer Tokenやクレームが改ざんされていないかをチェック可能。
• CSRF（XSRF）や

User-Agentやスマホネイティブでの外部ログインについての考察 †

概要 †

だからといって、User-Agentやスマホネイティブで上記に習い、
OAuth 2.0の「Implicitグラント種別」でClientではなく、
User-Agentやスマホネイティブに返したクレームを使ってサーバ認証
・・・というのも意味不明な（認証になって無い）仕様なので、

結局、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);

• Resource Owner Password Credentials、Client Credentialsグラント種別
  TokenエンドポイントでAccess Tokenの発行処理を行なう場合、

  // 検証完了
  context.Validated(identity);

参考 †

• OAuth
• ASP.NET Identityの外部ログイン
• ASP.NET IdentityによるSTS実装
  • ASP.NET IdentityのOAuthによるSTS実装?

---

Tags: :認証基盤, :ASP.NET Identity, :OAuth

     

Site admin: dotNetDevelopmentInfrastructure

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.023 sec.