このセクションの内容:
はじめに
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 本足シナリオ)。HTTP トランスポートの [OAuth 認証] セクションで、OAuth 1.0a の OAuth 認証設定を構成できます。OAuth 2.0 の場合、認証は REST Client の [リソース] タブと [ペイロード] タブで構成されます。
OAuth 2.0
OAuth 2.0 RFC は、認証にさまざまな「フロー」または「許可タイプ」を指定しています。
- 認証コード (Web サーバー) フロー
- クライアント資格情報フロー
- デバイス コード
- リフレッシュトークン
このドキュメントでは、最も一般的な 2 つのフロー、すなわち 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
承認をリクエストする
- プロジェクト フォルダーを右クリックし、[新規追加] > [テスト (.tst) ファイル] を選択します。
- テストの名前を指定して [Web] > [Webシナリオの記録] を選択します。
- [次へ] をクリックし、[新規機能テストの記録] を選択します。
- [次から記録を開始] フィールドで OAuth URL パラメーターを指定します。
- [終了] をクリックし、アプリケーションにログインします。承認されると、サービス プロバイダーは、URL パラメーターの一部としてコードを使用してコールバック URL にリダイレクトします。
- ブラウザーを閉じて記録を完了します。
- [リクエスト] > [ヘッダーの検証] ノードを右クリックし、[出力を追加] > [HTTPトラフィック] を選択します。
- [次へ] をクリックし、アクセス コードを含むリダイレクトされた URL を選択します。
- [次へ] をクリックし、Text Data Bank を選択してコードを抽出します。
アクセス トークンを取得する
- 新しい REST Client を作成し、URL に必要なパラメーターを指定します。URL パラメーターの 1 つは
code
と呼ばれる必要があります。この値は、前のステップからの Text Data Bank 抽出に対してパラメータライズする必要があります。 - レスポンス形式に応じて、適切な Data Bank(つまり、Text、JSON)を REST Client に接続し、アクセス トークンを抽出します。
保護されたリソースへのアクセス
すべての REST API 呼び出しについて、新しい REST Client を作成し、必要な URL パラメーターと共に目的の URL を渡します。URL パラメーターの 1 つは oauth_token
と呼ばれる必要があり、前のテスト ステップで抽出したアクセス トークンの値を持ちます。
クライアント資格情報フロー
この許可タイプは、ユーザーのコンテキスト外でアクセス トークンを取得するためにクライアントによって使用されます。これは通常、クライアントがユーザーのリソースにアクセスするのではなく、自分自身に関するリソースにアクセスするために使用されます。このフローの詳細については、OAuth 2.0 Framework のドキュメントを参照してください。https://tools.ietf.org/html/rfc6749#section-4.4
アクセス トークンを取得する
- テスト スイートに REST Client を追加します。わかりやすくするために、クライアントの名前を変更できます。たとえば Obtain Access Token など。
- [リソース] タブをクリックして [メソッド] ドロップダウン メニューから POST を選択します。
- URL フィールドで認証サーバーのエンドポイントを指定します。
- [ペイロード] タブをクリックし、[形式] メニューから [URLエンコード] を選択します。
[入力モード] メニューから [テーブル] を選択し、次のパラメーターを設定します。
パラメーター 説明 必須 client_id
client_secret
これらのパラメーターは、認証サーバーで認証するための資格情報を提供するために使用できます。ただし、これらのパラメーターを送信する代わりに、HTTP 認証を使用して認証可能です。
HTTP 認証を使用する場合は、代わりに [HTTP オプション] > [セキュリティ] > [HTTP 認証]で資格情報を入力してください。
時々 grant_type
値は client_credentials
でなければなりませんYes scope
このパラメーターは、アプリケーションへの制限付きアクセスを要求するためにクライアントによって使用されます。
認証サーバーに固有の値のカンマ区切りリストを指定してください。指定しない場合、認証サーバーはリクエストを拒否するか、デフォルトのスコープでアクセス トークンを返します。認証サーバーは、クライアントがここで最初に要求したものとは異なるスコープのアクセストークンを返す場合もあります。
詳細については https://oauth.net/2/scope/ を参照してください。
時々 audience
リソース サーバーの URI を指定します。このパラメーターは、アクセス トークンのアクセスが制限されるサーバーを示すために必要になる場合があります。 時々 REST Client を実行し、レスポンス メッセージを確認します。レスポンスの例:
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"Bearer", "expires_in":3600, "scope":"read_something" }
- REST Client を右クリックし、[出力の追加] をクリックします。
- [レスポンス] > [トラフィック] > [JSON Data Bank]を選択し、[終了] をクリックします。
access_token
値とtoken_type
値の抽出を作成します。次のセクションでは、抽出に対応するようにデータ バンク列に access_token および token_type という名前を付けていることを前提としています。
保護されたリソースへのアクセス
これで、クライアントは、JSON データバンクから抽出されたアクセス トークンを含めることで、保護されているすべてのリソースを呼び出すことができます。
- テスト スイートに REST Client を追加します。
- [リソース] タブをクリックし、予想されるパラメーターを含め、REST コール メソッドとエンドポイントを指定します。
- [HTTPオプション] タブをクリックして、[HTTPヘッダー] 設定を選択します。
- 名前が
Authorization
で値が${token_type} ${access_token}
の HTTP ヘッダーを追加します。${token_type}
および${access_token}
の値は、前のテストで作成した JSON Data Bank の列の名前と一致する必要があります。単一のスペースで値を区切る必要があります。 - シナリオを実行し、送信されたと予想される HTTP リクエスト ヘッダーを確認します。承認ヘッダーの例:
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
OAuth 1.0a
OAuth 1.0a に対する認証には、次の一般的な手順が含まれます。
- サービス プロバイダーからリクエスト トークンを取得して承認します
- リクエスト トークンをアクセス トークンと交換します
- 保護されたリソースにアクセスするための OAuth リクエストに署名します
次の例では、REST Client を使用してリクエスト メッセージをサーバーに送信します。または、Messaging Client を同じ方法で使用することもできます。
サービス プロバイダーからリクエスト トークンを取得して承認
- 新しい REST Client を作成し、リクエスト トークンを取得する場所の設定を構成します。
- [HTTP オプション] をクリックし、[トランスポート] メニューから HTTP1.0 または HTTP1.1] 選択します。
- [OAuth 認証] 設定をクリックし、[認証の実行] オプションを有効にします。OAuth 認証の構成を完了するために必要な他のフィールドがアクティブになります。
- [コンシューマー キー] フィールドと [コンシューマー シークレット] フィールドにコンシューマー キーとコンシューマー シークレットをそれぞれ入力します。
- [OAuth モード] メニューから [リクエスト トークンの取得] を選択します。
- (オプション) [スコープ] フィールドでスコープを指定します。
- (オプション) OAuth パラメーターの下にさらに OAuth パラメーターを追加します。
- Text Data Bank を REST Client の Response Traffic に接続し、リクエスト トークンとリクエスト トークン シークレットを抽出します。トークンは通常、
oauth_token
として示されます。 - メイン メニューから [ファイル] > [新規作成] > [テスト ファイル (.tst)] を選択し、プロジェクトを選択します。
- ファイル名を入力し、[次へ] をクリックします。
- [Web] > [Web シナリオの記録] を選択し、[次へ] をクリックします。
- [新規機能テストの記録] を選択し、[次へ] をクリックします。
- [次から記録を開始] フィールドに、検証コードを取得するための URL を入力します。
oauth_token
パラメーターを追加し、ステップ 8 で取得したリクエスト トークンの値を指定します。
ブラウザーが起動すると、保護されたリソースをホストしているサーバーのログイン ページが表示されます。 - ユーザーのログイン資格情報(ユーザー名/パスワード)を入力してサインインします。承認されると、ブラウザーは検証コードを含む新しいページにリダイレクトします。
- 検証コードが表示されたら、ブラウザーを閉じて記録を終了します。
- Browser Data Bank を Browser Contents(レンダリングされたHTML)に添付し、検証コードの値を抽出します。
- Browser Playback ツールを開き、リテラルのリクエスト トークン文字列を、Text Data Bank によって生成されたリクエスト トークン データソース列に置き換えます(ステップ7)。以下に示すように
${varName}
構文を使用します。
リクエスト トークンをアクセス トークンと交換する
- 新しい REST Client を作成し、リクエスト トークンをアクセス トークンと交換する場所の設定を構成します。
- [HTTP オプション] をクリックし、[トランスポート] メニューから HTTP1.0 または HTTP1.1] 選択します。
- [OAuth 認証] 設定をクリックし、[認証の実行] オプションを有効にします。OAuth 認証の構成を完了するために必要な他のフィールドがアクティブになります。
- [コンシューマー キー] フィールドと [コンシューマー シークレット] フィールドにコンシューマー キーとコンシューマー シークレットをそれぞれ入力します。
- [OAuth モード] メニューから [リクエスト トークンとアクセス トークンの交換] を選択します。
- Text Data Bank の抽出から [リクエスト トークン] フィールドと [リクエスト トークンのシークレット] フィールドをパラメータライズします。
- Browser Data Bank の [検証コード] フィールドをパラメータライズします。
- Text Data Bank を REST Client の Response Traffic に連結し、アクセストークン (通常 oauth_token) とアクセス トークン シークレット (通常 oauth_token_secret) を抽出します。
OAuth リクエストに署名して保護されたリソースにアクセスする
- 新しい REST Client を作成し、リクエスト トークンをアクセス トークンと交換する場所の設定を構成します。
- [HTTP オプション] をクリックし、[トランスポート] メニューから HTTP1.0 または HTTP1.1] 選択します。
- [OAuth 認証] 設定をクリックし、[認証の実行] オプションを有効にします。OAuth 認証の構成を完了するために必要な他のフィールドがアクティブになります。
- [コンシューマー キー] フィールドと [コンシューマー シークレット] フィールドにコンシューマー キーとコンシューマー シークレットをそれぞれ入力します。
- [OAuth モード] メニューから ["OAuth 認証のリクエストに署名] を選択します。
- Text Data Bank の抽出から [アクセス ークン] フィールドと [アクセス トークンのシークレット] フィールドをパラメータライズします。
- ユーザーのプライベート リソースを要求します。これは、アクセス トークンが取得されているために可能であるはずです。