Multi-AuthSystem独自仕様 のバックアップ(No.5)

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

• バックアップ一覧
• ソース を表示
• Multi-AuthSystem独自仕様 は削除されています。
  • 1 (2016-12-20 (火) 09:04:23)
  • 2 (2016-12-20 (火) 11:45:53)
  • 3 (2016-12-20 (火) 18:38:18)
  • 4 (2016-12-20 (火) 20:09:06)
  • 5 (2016-12-21 (水) 12:59:03)
  • 6 (2016-12-22 (木) 13:16:40)
  • 7 (2016-12-22 (木) 17:38:51)

---

Open棟梁 wiki

• 戻る?

目次 †

概要 †

Multi-AuthSystem?独自仕様部分について説明する。

Idp仕様 †

Idpの使用について。

UserStore? †

• EntityFramework?をキャンセルしUserStore?クラスで実装。
• DBMSはSQL Server or PostgreSQLを使用。
• Open棟梁のB・D層を使用してデータアクセスを実装。

パラメタ †

ASP.NET Identityや、その他、アプリケーションで使用するパラメタについて。

外部認証仕様 †

外部認証の使用について。

• 外部認証で取得したe-mail addressは検証しない。
• e-mail addressでサインアップして、そのままサインインする。
• 初回のサインアップを外部認証で行った場合、パスワードを持たないアカウントになる。
  この場合、後からパスワードを持ったアカウントとしての登録が不可能になる（★パスワードリセット不可能？）。

OAuth2.0 Server仕様 †

ASP.NET Identityの仕様については、「ASP.NET Identity追加仕様」を参照。

共通 †

Server側 †

• AuthorizationServer?
  • 認可エンドポイント
    • redirect_uriチェックは不要（部分一致をサポートしない完全事前登録制とするため）
  • Tokenエンドポイント（Access Tokenの発行方法）
    • scope=その他の値の場合、scopeパラメタ値をClaimに格納する（通常の動作）。

• ResourceServer?
  • リソース・アクセス用のWebAPIを提供する。
    • "urn:oauth:scope"のClaimがあった場合、scopeの値に適合した範囲のアクセス権で処理を行う。

Client側 †

• パラメタ
  • redirect_uri指定は不要（部分一致をサポートしない完全事前登録制とするため）
  • stateの使用を強く推奨する（Access Token露見は、Client側の自己責任のため）。

• ResourceServer?リソース・アクセス用のWebAPIにアクセスする場合、
  • Access TokenをHTTPヘッダに指定して送信する。

Access Tokenへの情報格納方法 †

ClaimsIdentity?を使用する。以下のようなURN形式をkeyに使用してvalueの追加を行う。

• "scope=auth"の場合（Access Tokenがユーザ認証用であることを意味する。詳しくは下記参照）

  claimsIdentity.AddClaim(new Claim("urn:oauth:auth", client_id));

• "scope=その他の値"の場合、

  claimsIdentity.AddClaim(new Claim("urn:oauth:scope", scope));

クライアント認証 †

• 認可エンドポイントでは、クライアント認証ではなく、Redirectエンドポイントの検証を行う。
• クライアント認証は、Tokenエンドポイントにアクセスする際に行なう。
• ベーシック認証の認証ヘッダを使用してクライアント識別子を送信する。

クライアント識別子 †

• GUIDを使用する
  • 32文字の英数字。
  • URLに指定するので、[{}, -] は無し。

• client_id
  全てのグラント種別以外で必須
• client_secret
  • Implicitグラント種別以外で必須
  • ただし、ユーザ認証で使用する場合は、Implicitグラント種別でも必須。

ユーザ認証 †

• ユーザ認証に利用する場合、以下の仕様に準拠する。
• クライアント識別子は全てのグラント種別で必須

Server側 †

• AuthorizationServer?
  • Tokenエンドポイント（Access Tokenの発行方法）
    • scope=authの場合、client_idをClaimに格納し、Access Tokenがユーザ認証用であることを明示する。

• ResourceServer?
  • ユーザ認証専用のWebAPIを提供する。
    • "urn:oauth:auth"のClaimがあった場合、Access Tokenがユーザ認証用であることを意味する。
    • この場合、POSTされたクライアント識別子でクライアント認証をした後、
      そのClaim値とclient_idを比較してTokenに問題がないかをチェックする。

Client側 †

• グラント種別
  • できるだけ、Authorization Codeグラント種別を使用する。
  • Implicitグラント種別もサポートするが、その場合、
    ユーザ認証用Access Tokenとクライアント識別子の露見のリスクがあることに注意すること。

• パラメタ
  • response_typeには、"code"(推奨) or "token"を指定する。
  • ユーザ認証を行なう場合、scopeパラメタに"auth"を指定する。

• ResourceServer?のユーザ認証専用のWebAPIにアクセスする場合、
  • ユーザ認証用Access Tokenに加え、前述のクライアント識別子をPOSTで送信する。

ResourceServer?のWebAPI †

• 認証専用のWebAPI
  • /api/OAuthResourceApi?/GetAuthenticatedUsersClaim?

• リソース・アクセス用のWebAPI
  • /api/OAuthResourceApi?/XXXXX

動作検証 †

Authorization Codeグラント種別 †

「http://localhost:XXXXX/home/index」で表示されるAuthorization Codeグラント種別のテスト用linkをclickする。

Implicitグラント種別 †

「http://localhost:XXXXX/home/index」で表示されるImplicitグラント種別のテスト用linkをclickする。

Resource Owner Password Credentialsグラント種別 †

• cURLコマンド?を使用して認証専用WebAPIへのアクセスを検証する。
  • 認証の拡張仕様の部分は、朱書きにしてある。
  • 通常のリソース用WebAPIへのアクセス時はこのパラメタの指定は不要。

• 処理の概要

• Tokenエンドポイントに対して以下のRequestを出すと、Bearer Tokenが返ってくる。
  • POST
  • Authorization: Basic ZZZZZZZZZZ ---> 「クライアントID:クライアント・パスワード」をBase64エンコードしたもの。
  • body : grant_type=password, username=ユーザID, password=ユーザ・パスワード, scope=auth

• Bearer Tokenをヘッダに指定して認証専用のWebAPIにアクセスすると認証情報を取得できる。
  • POST
  • Authorization: Bearer XXXXXXXXXX
  • body : client_id=クライアントID, client_secret=クライアント・パスワード

• cURLコマンド?
  Debug ProxyにFiddler等を使用すると尚良（其の際は、 --proxy オプションを指定する必要がある）。

• Bearer Tokenの取得

• Request (cURLコマンド)

  >curl "http://localhost:nnnnn/OAuthBearerToken"-u "クライアントID:クライアント・パスワード" -d "grant_type=password" -d "username=ユーザID" -d "password=ユーザ・パスワード" -d "scope=auth"

• Response (Body)

  {"access_token":"XXXXXXXXXX","token_type":"bearer","expires_in":nnnnn,"refresh_token":"YYYYYYYYYY"}

• Bearer Tokenを使用したOAuthリソースへのアクセス

• Request (cURLコマンド)

  >curl "http://localhost:nnnnn/api/OAuthResourceApi/GetAuthenticatedUsersClaim" -H "Authorization: Bearer XXXXXXXXXX" -d "client_id=クライアントID" -d "client_secret=クライアント・パスワード"

• Response (Body)

  {"userName":"XXXXX","email":"XXXXX","phoneNumber":"XXXXX"}

Client Credentialsグラント種別 †

cURLコマンド?を使用して動作を検証する。

• 処理の概要

• Tokenエンドポイントに対して以下のRequestを出すと、Bearer Tokenが返ってくる。
  • POST Authorization: Basic ZZZZZZZZZZ ---> 「クライアントID:クライアント・パスワード」をBase64エンコードしたもの。
  • body:grant_type=client_credentials

• Bearer Tokenをヘッダに指定して認証専用のWebAPIにアクセスすると認証情報を取得できる。
  • POST
  • Authorization: Bearer XXXXXXXXXX
  • body : client_id=クライアントID, client_secret=クライアント・パスワード

• cURLコマンド?
  Debug ProxyにFiddler等を使用すると尚良（其の際は、 --proxy オプションを指定する必要がある）。

• Bearer Tokenの取得

• Request (cURLコマンド)

  >curl "http://localhost:nnnnn/OAuthBearerToken" -u "クライアントID:クライアント・パスワード" -d "grant_type=client_credentials" -d "scope=auth"

• Response (Body)

  {"access_token":"XXXXXXXXXX","token_type":"bearer","expires_in":nnnnn,"refresh_token":"YYYYYYYYYY"}

• Bearer Tokenを使用したOAuthリソースへのアクセス

• Request (cURLコマンド)

  >curl "http://localhost:63359/api/OAuthResourceApi/GetAuthenticatedUsersClaim" -H "Authorization: Bearer XXXXXXXXXX" -d "client_id=クライアントID" -d "client_secret=クライアント・パスワード"

• Response (Body)

  {"userName":"XXXXX","email":"XXXXX","phoneNumber":"XXXXX"}

     

Site admin: OpenTouryo

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.030 sec.