OAuth Authentication

はじめに

OAuth (Open Authorization) 認証プロトコルを使用すると、ユーザーは、ログイン資格情報を公開せずに、サードパーティアプリケーションにプライベートリソースへのアクセスを許可できます。また、アクセスできる情報の量を制限することもできます。

OAuthは、ユーザー ロール (別名 リソース所有者) を従来のクライアントサーバー認証モデルに導入します。従来のクライアントサーバー認証モデルでは、クライアントはサーバーでホストされているリソースに直接アクセスします。OAuth モデルでは、クライアントはサーバーからリソースにアクセスする前に、まずリソース所有者から許可を取得する必要があります。この許可は、トークンと一致する共有秘密鍵の形式で表されます。

OAuth 2.0 と 1.0a は異なる実装であり、互換性がありません。詳細については、OAuth の Web サイトを参照してください: https://oauth.net/2/

サンプルシナリオ

ユーザー (リソース所有者) が、写真共有サービス (サーバー) に保存されている自分のプライベート写真へのアクセスを印刷サービス (クライアント) に許可したいとします。ユーザーのログイン資格情報を印刷サービスに公開する代わりに、ユーザーは OAuth 認証を実行して、印刷サービスに自分のプライベート写真にアクセスするためのアクセス許可を付与できます。これは 3 つの段階で発生します。

印刷サービスは、写真共有サービスに一時的な資格情報を要求します。
印刷サービスは資格情報を受け取ると、ユーザーを写真共有サービスの OAuth 認証 URL にリダイレクトし、ユーザーはログイン資格情報を提供します。このステップでは、印刷サービスはユーザーのログイン資格情報を認識できないことに注意してください。ユーザーが印刷サービスにプライベート写真へのアクセスを許可することを決定すると、検証コードが生成されます。
次に、印刷サービスは、一時的な資格情報と検証コードをアクセストークンと交換します。印刷サービスがアクセストークンを取得すると、写真共有サービスからユーザーのプライベート写真を取得して印刷できます。

OAuth に対する Parasoft のサポート

Parasoft は、Web サーバーフローとクライアント資格情報フローの OAuth 1.0a および 2.0 セキュリティプロトコルをサポートします (2 本足シナリオ)。OAuth 1.0a および OAuth 2.0 を使用した認証の構成については、以下で説明します。

OAuth 2.0

OAuth 2.0 RFC は、認証にさまざまな「フロー」または「許可タイプ」を指定しています。このドキュメントでは、最も一般的な 3 つのフローを SOAtest で使用する方法について説明します。PKCE があるまたはない Web サーバー (認証コード) フローとクライアントの資格情報フローです。

OAuth 2.0 フローの詳細については https://oauth.net/2/grant-types/ を参照してください。

Web サーバー (認証コード) フロー

この許可タイプは、アクセストークンの認証コードを交換するために confidential クライアントと public クライアントによって使用されます。ユーザーがリダイレクト URL を介してクライアントに戻った後、アプリケーションは URL から認証コードを取得し、それを使用してアクセストークンを要求します。このフローの詳細については、OAuth 2.0 Framework のドキュメントを参照してください: https://tools.ietf.org/html/rfc6749#section-4.1

SOAtest でこれをセットアップするには、まず、ログインスイートとして使用する認証コードを取得するテストシナリオを作成する必要があります。このログインスイートは、トークンを必要とするテストシナリオによって呼び出されます。認証コードを Proof Key for Code Exchange (PKCE) で使用するかどうかにかかわらず、手順は同じです。ただし、PKCE を使用する場合は、設定が必要な追加の変数がいくつか存在します。このログインテストスイートは、ウィザードを使用して作成することも、手動で設定することもできます。ログインテストスイートを作成したら、テストシナリオを設定して、そのスイートを使用してトークンを取得できます。これにより、シナリオごとに毎回トークンを作成する必要がなくなります。

ログインテストスイートをウィザードで作成する

テストスイートを右クリックし、[新規追加] > [グローバルプロパティ] を選択します。
[認証] リストを展開し、[OAuth 2.0] を選択して [次へ] をクリックします。
付与タイプを Authorization Code または Authorization Code with PKCE に適宜設定し、[次へ] をクリックします。
[新規ログインスイートの記録] を選択し、[次へ] をクリックします。
ログインプロセスに応じて、記録を開始する URL と Chrome 実行可能ファイルへのパスを入力します。[終了] をクリックします。アプリケーションのログインページが開きます。
アプリケーションにログインします。プロセスが完了したら、[記録の停止] をクリックして記録を終了します。
ログインテストスイートを保存する親フォルダーを入力または選択し、名前を入力します。[終了] をクリックします。ダイアログが開き、以下の 3 つの重要事項が表示されます。
- 認可サーバーには、コールバック URL と一致するリダイレクト URI (デフォルトでは http://localhost:9080/servlet/oauth2/code) を設定する必要があります。
- 正しく機能させるには、このテストを使用するときには必ず SOAtest サーバーが実行されている必要があります。SOAtest サーバーのステータスは、SOAtest サーバービュー ([Parasoft] > [ビューの表示] > [SOAtest サーバー]) で確認できます。
- 認可サーバーでクライアントシークレットが必要な場合は、設定時に手動で入力する必要があります (詳細は後述)。ウィザードでは抽出できません。
[OK] をクリックしてダイアログを閉じます。OAuth 2.0 認証構成画面が開き、ログインスイートとウィザードによって抽出された設定が自動的に設定されます。
[名前] フィールドにわかりやすい名前を入力します。
以下の説明に従って、残りの設定を構成します。これらの設定の一部は自動的に抽出されますが、抽出できない設定は手動で入力する必要があります。設定を変更または入力する場合は、認証エンドポイント URL の設定と完全に一致していることを確認してください (該当する場合)。
- リダイレクト URI: デフォルトでは、コールバックツールを使用するように設定されており、URL は http://localhost:9080/servlet/oauth2/code に設定されています。これは推奨される構成ですが、必要に応じて変更できます。
- トークン URI: OAuth 2.0 認証サーバーのアクセストークンエンドポイントを指定します。
- クライアント ID: 認証サーバーでの認証に必要なクライアント ID を指定します。
- クライアントシークレット: 認可サーバーでの認証に必要なクライアントシークレットを入力します。これはウィザードでは抽出できないため、必要な場合は手動で入力する必要があります。
- スコープ: これは、アプリケーションへの制限付きアクセスを要求するためにクライアントによって使用されます。必要に応じて、認可サーバー固有の値のカンマ区切りリストを入力するか、パラメータライズされた値を入力できます。詳細については https://oauth.net/2/scope/ を参照してください。スコープが指定されていない場合、デフォルトのスコープが返されることがあります。
- オーディエンス: 必要に応じて、リソースサーバーの URI またはパラメータライズされた値を入力します。これはウィザードでは抽出できないため、該当する場合、手動で入力する必要があります。
- コードベリファイア (Authorization Code with PKCE のみ): コードベリファイアを生成する方法を選択します。デフォルトでは、これは自動的に行われます。この方法が推奨されています。自動生成されたコードベリファイアは OAuth 2.0 標準に準拠し、文字 A ～ Z、a ～ z、0 ～ 9、および - . _ ~ (ハイフン、ピリオド、アンダースコア、チルダ) を使用した暗号的にランダムな文字列であり、長さは 43 から 128 文字です。別の方法を選択する場合は、結果が同じ基準を満たしていることを確認してください。そうしないと、トークンリクエストが拒否される可能性があります。
- Challenge Method (Authorization Code with PKCE のみ): コードチャレンジがプレーンテキストバージョンのコードベリファイアであるか、SHA-256 バージョンのコードベリファイアであるかを選択します。
ヘッダーを使用してアクセストークンを送信するか、クエリパラメーターを使用して送信するかを選択します。
構成を保存します。

ログインテストスイートを手動で作成する

開始する前に、[SOAtest サーバー] ビューでローカル SOAtest サーバーが実行されていることを確認してください。ワークスペースに [SOAtest サーバー] ビューが表示されていない場合、[Parasoft] メニューの [ビューの表示] > [SOAtest サーバー] をクリックします。サーバーを起動するには、サーバーノードをクリックしてからパネルの右上隅にある開始アイコンをクリックするか、サーバーノードを右クリックして [サーバーの起動] を選択します。

ローカル SOAtest サーバーが実行中であることを確認したら、次の手順を実行します。

プロジェクトフォルダーを右クリックし、[新規追加] > [テスト (.tst) ファイル] を選択します。
テストの名前を指定し、[Web] > [Web シナリオの記録] を選択します。
[次へ] をクリックし、[新規 Web シナリオの記録] を選択します。
[次から記録を開始] フィールドに認証エンドポイント URL の URL を入力し、[次へ] をクリックします。
テスト対象アプリケーション (AUT) の URL は使用しないでください。これは、認証エンドポイント (つまりログインページ) に自動的にリダイレクトされます。認証エンドポイント自体の URL を使用する必要があります。そうしないと、テストでトークンを使用する前にテスト対象アプリケーションがトークンを消費します。
[既存の環境に URL 変数を追加] を有効にして、[終了] をクリックします。アプリケーションのログインページが開きます。
アプリケーションにログインします。承認されると、サービスプロバイダーは、URL パラメーターの一部としてコードを使用してコールバック URL にリダイレクトします。
ブラウザーを閉じて記録を完了します。
テストを 1 回実行して、テストにトラフィックを入力します。
テストスイートノードを右クリックし、[新規追加] > [テスト] を選択します。[テストの追加] ダイアログが表示されます。
[セットアップテスト] > [Data Generator ツール] を選択し、[終了] をクリックします。ワークスペースで Data Generator ツールが開きます。
Data Generator ツールで、[追加] をクリックし、[文字列] を選択して [終了] をクリックします。
"########" というパターンを入力し、データ列名として OAUTH2_STATE と入力します。
変更を保存します。
認証エンドポイントをパラメータライズします。ログインスイートで認証エンドポイントのパラメーターを設定すると、OAuth 2.0 共有認証機能を使用した多くのテストで参照される汎用ログインスイートとしての適応性が高まります。操作手順は以下のとおりです。
1. 記録されたシナリオで認証エンドポイントに移動するテストを開き (通常、これは最初のテストです)、[ユーザーアクション] タブを選択します。
2. [URL] フィールドで、必要に応じて、次のパラメーターを静的な値から指定されたテストスイート変数に変更します (該当する場合):
  パラメーター変数
  client_id ${OAUTH2_CLIENT_ID}
  redirect_uri ${OAUTH2_REDIRECT_URI}
  scope ${OAUTH2_SCOPE}
  audience ${OAUTH2_AUDIENCE}
  state ${OAUTH2_STATE}
  - 付与タイプとして Authorization Code with PKCE を選択した場合は、追加のパラメータライズ要件について次の手順を参照してください。
3. 変更を保存します。
PKCE ありの認証コードを使用している場合、認証エンドポイントは、code_challenge および code_challenge_method パラメーターの変数を受け入れるように設定する必要があります。そのためには:
1. 記録されたシナリオで認証エンドポイントに移動するテストを開き (通常、これは最初のテストです)、[ユーザーアクション] タブを選択します。
2. [URL] フィールドで、次のパラメーターを静的な値から指定されたテストスイート変数に変更します。
  パラメーター変数
  code_challenge ${OAUTH2_CODE_CHALLENGE}
  code_challenge_method ${OAUTH2_CODE_CHALLENGE_METHOD}
3. 変更を保存します。
テストスイートノードを右クリックし、[新規追加] > [テスト] を選択します。[テストの追加] ダイアログが表示されます。
[セットアップテスト] > [Call Back ツール] を選択し、[終了] をクリックします。ワークスペースで Call Back ツールが開きます。
プロトコルとして OAuth 2.0 を選択し、状態として "パラメータライズ" を選択します。列名として OAUTH2_STATE を選択します。
変更を保存します。
適切な Call Back ツールノードを右クリックし、[出力の追加] を選択します。[出力の追加] ダイアログが表示されます。
[受信リクエスト] > [トランスポートヘッダー] > [REST URL Data Bank] を選択し、[終了] をクリックします。ワークスペースに REST URL Data Bank の出力が開きます。
"パラメーター" を選択し、[追加] をクリックします。追加されたデフォルトのパラメーターをダブルクリックし、パラメーター名に code、カスタム列名に OAUTH2_AUTHORIZATION_CODE と入力します。
変更を保存します。

上記の変数の 1 つ以上を設定して認証エンドポイントをパラメータライズしたが、それでも Web シナリオを個別に実行できるようにしたい場合は、[変数] タブでパラメータライズされた値のデフォルト値を設定できます。詳細については、テストスイートのプロパティ設定 (テストフローロジック、変数など) ページの「変数の定義」を参照してください。

テストシナリオを作成する

テストシナリオを作成するプロジェクトを右クリックし、[新規追加] > [テスト (.tst) ファイル] を選択します。アプリケーションとテストのニーズに合わせて、このシナリオの作成を完了します。使用するシナリオが既にある場合は、この手順を省略できます。
負荷テスト
このシナリオの負荷テストを行う場合は、テストをグループとして実行するようにテストスイートを構成する必要があります (テストスイートを開き、[実行オプション] > [テスト実行] タブに移動します)。テストスイートが [個別にテストを実行可能] オプションを有効にして構成されている場合、OAuth 2.0 アクセストークンを再利用することなく各仮想ユーザーはスイート内のテストの 1 つを分離して実行します。そして Load Test は新しいアクセストークンを取得するためにログインスイートを繰り返し実行する必要があります。
テストシナリオを右クリックし、[新規追加] > [テスト] をクリックします。メソッドを GET に、URL を AUT に設定して、テストシナリオで新しい REST クライアントを作成します。
以前に作成した共有認証がこのテストスイート用に作成された唯一のものである場合、それが自動的に使用されます。それ以外の場合は、[セキュリティ] の下の [認証] をクリックし、[認証] ペインの最初のドロップダウンメニューから [カスタム] を選択します。
シナリオを実行し、OAuth 2.0 トークンが取得されて正常に使用されたことを確認します。

クライアント資格情報フロー

この許可タイプは、ユーザーのコンテキスト外でアクセストークンを取得するためにクライアントによって使用されます。これは通常、ユーザーのリソースにアクセスするためではなく、クライアントアプリケーションによって自身に関するリソースにアクセスするために使用されます。このフローの詳細については、OAuth 2.0 Framework のドキュメントを参照してください: https://tools.ietf.org/html/rfc6749#section-4.4

テストスイートの共有 OAuth 2.0 認証を設定する

テストスイートを右クリックし、[新規追加] > [グローバルプロパティ] を選択します。
[認証] リストを展開し、[OAuth 2.0] を選択して [次へ] をクリックします。
付与タイプを クライアント認証情報 に設定し、[終了 ]をクリックします。OAuth 2.0 認証の設定画面が開きます。
[名前] フィールドにわかりやすい名前を入力します。
残りの設定を行います:
- トークン URI: OAuth 2.0 認証サーバーのアクセストークンエンドポイントを入力します。
- クライアント ID: 認証サーバーでの認証に必要なクライアント ID を入力します。
- クライアントシークレット: 認可サーバーでの認証に必要なクライアントシークレットを入力します。
- スコープ: (オプション) アクセストークンのスコープを指定します。複数のパラメーターが必要な場合は、カンマで区切ります。詳細については https://oauth.net/2/scope/ を参照してください。スコープが指定されていない場合、デフォルトのスコープが返されることがあります。
- オーディエンス: (オプション) リソースサーバーの URI を入力します。
ヘッダーを使用してアクセストークンを送信するか、クエリパラメーターを使用して送信するかを選択します。
構成を保存します。

テストシナリオを作成する

テストスイートを右クリックし、[新規追加] > [テスト] をクリックします。テストスイートに新しい REST クライアントを作成します。
[HTTP オプション] タブをクリックし、[トランスポート] メニューから HTTP 1.0 または HTTP 1.1 を選択します。
以前に作成した共有認証がこのテストスイート用に作成された唯一のものである場合、それが自動的に使用されます。それ以外の場合は、[セキュリティ] の下の [認証] をクリックし、[認証] ペインの最初のドロップダウンメニューから [カスタム] を選択します。
[リソース] タブをクリックし、必要なパラメーターを含めて、REST 呼び出しメソッドとエンドポイントを指定します。
- OAuth 2.0 アクセストークンが自動的に挿入されます。
シナリオを実行し、送信されたと予想される HTTP リクエストヘッダーを確認します。認証ヘッダーの例：
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA

負荷テストに関する考慮事項

シナリオのロードテストを行う場合は、その親テストスイート ([実行オプション] > [テスト実行] タブにあります) で [グループとしてテストを実行] を有効にする必要があります。このオプションでは、各仮想ユーザー (VU) がシナリオ全体を実行できるため、各 VU は独自の OAuth 2.0 アクセストークンを取得して再利用できます。代わりに [個別にテストを実行可能] を有効にすると、各 VU はスイートから 1 つのテストを分離して実行します。このとき、アクセストークンは再利用せず、各テストが独自のトークンを取得します。その結果、新しいアクセストークンを取得するためにログインスイートが繰り返し実行されます。

トラブルシューティング

OAuth 2.0 に関連するエラーは、通常、OAuth 2.0 認証コードを取得する際のエラーとアクセストークンを取得する際のエラーの 2 つのタイプに分類できます。トラブルシューティングを開始する前に、[品質タスク] ビューでエラーを確認して、発生している問題の種類を特定してください。

認証コードの取得に問題がある場合:

ログインスイートを直接実行して、期待どおりに動作することを確認してください。
- ログインスイートで認証エンドポイントをパラメータライズした場合でも、[変数] タブでパラメータライズされた値のデフォルト値を設定することで、独立して実行できます。詳細については、「テストスイートのプロパティ設定 (テストフローロジック、変数など)」の「変数の定義」を参照してください。
テストの実行中にコンソールビューでメッセージを確認します。

問題がアクセストークンの取得にある場合:

[品質タスク] ビューで OAuth 2.0 エラーに関連するトラフィックを右クリックし、[関連するトラフィックの表示] を選択して、関連するトラフィックを確認します。

OAuth 1.0a

OAuth 1.0a に対する認証には、次の一般的な手順が含まれます。

サービスプロバイダーからリクエストトークンを取得して承認します。
リクエストトークンをアクセストークンと交換します。
保護されたリソースにアクセスするための OAuth リクエストに署名します。

次の例では、REST Client を使用してリクエストメッセージをサーバーに送信します。または、同じ方法で Messaging Client を使用することもできます。

サービスプロバイダーからリクエストトークンを取得して承認

新しい REST Client を作成し、リクエストトークンを取得する場所の設定を構成します。
[HTTP オプション] タブをクリックし、[トランスポート] メニューから HTTP 1.0 または HTTP 1.1 を選択します。
[セキュリティ] の下の [認証] をクリックします。
[認証] ペインの最初のドロップダウンメニューから [カスタム] を選択します。
- リクエストトークンを取得するように構成された OAuth 1.0 共有認証がテストスイートに設定されている場合 (「テストスイートのプロパティ設定 (テストフローロジック、変数など)」の「クライアントオプションの指定」を参照)、2 番目のドロップダウンメニューからそれを選択し、手順 11 にスキップできます。
[新規] をクリックし、[OAuth 1.0] を選択して [終了] をクリックします。テストスイートの認証ノードに OAuth 1.0 認証が追加されます (これがテストスイートに追加された最初のカスタム認証である場合、認証ノードは自動的に作成されます)。
[名前] フィールドにわかりやすい名前を入力します。
[コンシューマーキー] フィールドと [コンシューマーシークレット] フィールドに、コンシューマーキーとコンシューマーシークレットを入力します。
[モード] メニューから [リクエストトークンの取得] を選択します。
(オプション) [スコープ] フィールドでスコープを指定します。
(オプション) [パラメーター] の下に追加の OAuth パラメーターを追加します。
Text Data Bank を REST Client の Response Traffic に接続し、リクエストトークンとリクエストトークンシークレットを抽出します。トークンは通常、oauth_token として示されます。
メインメニューから [ファイル] > [新規作成] > [テストファイル (.tst)] を選択し、プロジェクトを選択します。
ファイルの名前を入力し、[次へ] をクリックします。
[Web] > [Web シナリオの記録] を選択し、[次へ] をクリックします。
[新規 Web シナリオの記録] を選択し、[次へ] をクリックします。
[次から記録を開始] フィールドに、検証コードを取得するための URL を入力します。oauth_token パラメーターを追加し、手順 10 で取得したリクエストトークンの値を指定します。

ブラウザーが起動すると、保護されたリソースをホストしているサーバーのログインページが表示されます。
ユーザーのログイン資格情報（ユーザー名/パスワード）を入力してサインインします。承認されると、ブラウザーは検証コードを含む新しいページにリダイレクトします。
検証コードが表示されたら、ブラウザーを閉じて記録を終了します。
Browser Data Bank を Browser Contents（レンダリングされたHTML）に添付し、検証コードの値を抽出します。
Browser Playback ツールを開き、リテラルの Request Token 文字列を、Text Data Bank によって生成された Request Token データソース列に置き換えます (ステップ 10)。以下に示すように、${varName} 構文を使用します。

リクエストトークンをアクセストークンと交換する

新しい REST Client を作成し、リクエストトークンをアクセストークンと交換する場所の設定を構成します。
[HTTP オプション] をクリックし、[トランスポート] メニューから HTTP 1.0 または HTTP 1.1 を選択します。
[セキュリティ] の下の [認証] をクリックします。
[認証] ペインの最初のドロップダウンメニューから [カスタム] を選択します。
- リクエストトークンをアクセストークンと交換するように構成された OAuth 1.0 共有認証がテストスイートに設定されている場合 (「テストスイートのプロパティ設定 (テストフローロジック、変数など)」の「クライアントオプションの指定」を参照)、2 番目のドロップダウンメニューからそれを選択して手順 10 に進むことができます。
[新規] をクリックし、[OAuth 1.0] を選択して [終了] をクリックします。テストスイートの認証ノードに OAuth 1.0 認証が追加されます (これがテストスイートに追加された最初のカスタム認証である場合、認証ノードは自動的に作成されます)。
[コンシューマーキー] フィールドと [コンシューマーシークレット] フィールドに、コンシューマーキーとコンシューマーシークレットを入力します。
[モード] メニューから [リクエストトークンとアクセストークンの交換] を選択します。
Text Data Bank の抽出からの Request Token フィールドと Request Token Secret フィールドをパラメータライズします。
Browser Data Bank. の [検証コード] フィールドをパラメータライズします。
Text Data Bank を REST Client の Response Traffic に連結し、アクセストークン (通常 oauth_token) とアクセストークンシークレット (通常 oauth_token_secret) を抽出します。

OAuth リクエストに署名して保護されたリソースにアクセスする

新しい REST Client を作成し、リクエストトークンをアクセストークンと交換する場所の設定を構成します。
[HTTP オプション] をクリックし、[トランスポート] メニューから HTTP 1.0 または HTTP 1.1 を選択します。
[セキュリティ] の下の [認証] をクリックします。
[認証] ペインの最初のドロップダウンメニューから [カスタム] を選択します。
- OAuth 認証のリクエストに署名するように構成された OAuth 1.0 共有認証がテストスイートに設定されている場合 (「テストスイートのプロパティ設定 (テストフローロジック、変数など)」の「クライアントオプションの指定」を参照)、2 番目のドロップダウンメニューからそれを選択し、手順 9 に進むことができます。
[新規] をクリックし、[OAuth 1.0] を選択して [終了] をクリックします。テストスイートの認証ノードに OAuth 1.0 認証が追加されます (これがテストスイートに追加された最初のカスタム認証である場合、認証ノードは自動的に作成されます)。
[コンシューマーキー] フィールドと [コンシューマーシークレット] フィールドに、コンシューマーキーとコンシューマーシークレットを入力します。
[モード] メニューから [OAuth 認証のリクエストに署名] を選択します。
Text Data Bank の抽出からの Access Token フィールドと Access Token Secret フィールドをパラメータライズします。
ユーザーのプライベートリソースを要求します。これは、アクセストークンが取得されているために可能であるはずです。

パラメーター	変数
client_id	`${OAUTH2_CLIENT_ID}`
redirect_uri	`${OAUTH2_REDIRECT_URI}`
scope	`${OAUTH2_SCOPE}`
audience	`${OAUTH2_AUDIENCE}`
state	`${OAUTH2_STATE}`

パラメーター	変数
code_challenge	`${OAUTH2_CODE_CHALLENGE}`
code_challenge_method	`${OAUTH2_CODE_CHALLENGE_METHOD}`

Page tree