Fusion Applicationsアイデンティティ・ドメインを使用したOAuthの構成
Fusion Applicationのすべてのユーザーは、同期を介して自動的にFusion IAMドメインで使用でき、拡張がFusion Applications REST APIにアクセスするリクエストを送信すると、OAuthを使用できます。
OAuthは、生成されたトークン(JWTと呼ばれるJSON Webトークン)を使用して、必要なリソースへのアクセス権を付与します。 そのトークンを取得するプロセスには、いくつかのステップが含まれます。 Fusion Applicationsインスタンスに関連付けられたOracle Cloud Infrastructure Identity and Access Managementアイデンティティ・ドメインを使用して、OAuthフローを構成します。 このトピックでは、設定全体の理解に役立つ説明内容とともに、構成手順について説明します。
- 機密アプリケーションを作成するアイデンティティ・ドメインを特定します。 ドメインは認可サーバーになります。 ノート: 自分または他の必須ユーザーが、アイデンティティ・ドメインに移動するためにIdentity and Access Management管理コンソールにアクセスするために必要な権限を持っていることを確認します。
- OAuthフローを決定する付与タイプを指定します。 要件に基づいて、2-legged OAuthまたは3-legged OAuthを構成できます。
- アクセスの範囲を定義します。
- アクセス・トークンを生成します。
- トークンを使用してRESTリソースにアクセスします。
2-Legged OAuthおよび3-Legged OAuth
2-legged構成と3-legged構成の両方で、RESTリソースへのアクセスに必要なOAuthトークンが生成されます。 ただし、そのうちの1つを選択するディシジョンは、RESTリソースへのアクセスを認可する方法に基づいています。
2-legged OAuth構成で、アプリケーション(OAuthクライアントと呼ばれる)がRESTリソースに直接アクセスできるようにする場合は、「クライアント資格証明」付与タイプを使用してアクセスできます。 この構成では、クライアント資格証明をアプリケーションに格納し、かわりに認可サーバーにアクセス・トークンの提供をリクエストできます。 後で、そのトークンはリソース・サーバー上のRESTリソースへのアクセスをリクエストするために使用されます。 この場合、ユーザーの関与はありません。 ただし、ユーザーを関与させ、パスワードを使用してアクセス・トークンのリクエストを許可する場合は、「リソース所有者」権限タイプを使用できます。 次の図は、これら2つの権限付与タイプの2-legged OAuthフローの違いを理解するのに役立ちます。

一方、3-legged OAuthは、同様にセキュアな対話型ブラウザ・フローである可能性があります。 リソース所有者は、すでに認証されている必要があるか、構成されたサインイン・プロシージャを介して認証する必要があり、オプションで、アプリケーションまたはOAuthクライアントにリソースへのアクセスを許可するように要求できます。 リソース所有者がすでに認証されている場合、資格証明を入力する必要はありません。 OAuthクライアントは、認可サーバー(この場合はアイデンティティ・ドメイン)に登録する必要があります。 このフローでは、リクエストは認可サーバーを介してルーティングされ、リソース所有者はオプションで認可する必要があります。 認可サーバーは、認可コードをOAuthクライアントに渡します。 OAuthクライアントは、許可付与コードとその事前割当て済クライアント資格証明を許可サーバーに送信します。 検証に成功すると、認可サーバーはアクセス・トークンを生成し、それをOAuthクライアントと共有します。 最後に、クライアントはリソースにアクセスするためにアクセス・トークンをリソース・サーバーに渡します。
次の図に、フローについて説明します。

付与タイプとOAuthマッピング
付与タイプは、OAuthフローの重要なコンポーネントです。 認可サーバーからアクセス・トークンを取得するために使用されます。 OAuthフレームワークでは、リソースへのアクセス方法に基づいて様々な権限付与タイプがサポートされます。 一部の付与タイプは2-legged OAuth実装に適しており、その他の付与タイプは3-legged OAuth実装で使用することを目的としています。 次の表に、クラウド・アプリケーションにOAuthを実装するために一般的に使用される権限付与タイプを示します。
許可付与タイプ | 説明 | 2-legged OAuthで使用 | 3-legged OAuthで使用 |
---|---|---|---|
リソース所有者 | この場合、リソース所有者の資格証明は事前に取得され、クライアント・アプリケーションに格納されます。 クライアント・アプリケーションは、認可サーバーを持つ信頼できるアプリケーションです。 認可サーバーへのリクエストが行われると、リソース所有者の資格証明が検証され、アクセス・トークンが返されます。 | はい | いいえ |
承認コード | この付与タイプでは、クライアント・アプリケーションは、登録されたクライアントIDを使用して許可サーバーからの許可コードをリクエストします。 次に、受信した認可コードとともにクライアント資格証明を渡してアクセス・トークンを取得し、これを使用してリソース・サーバーからリソースにアクセスします。 | いいえ | はい |
クライアント資格証明 | クライアント・アプリケーションは、クライアント資格証明を使用して、リソース・サーバーへのアクセスを直接リクエストします。 検証は、登録されたクライアント・アプリケーションに対して認可サーバー内で行われ、アクセス・トークンがクライアント・アプリケーションに返されます。 | はい | いいえ |
JSON Webトークン(JWT)アサーション | クライアント・アプリケーションは、認可サーバーに登録する必要があるトークン・サービスからユーザー・アサーションJWTをリクエストします。 クライアントは、JWTを認可サーバーのトークン・エンドポイントに送信して、リソースへのアクセスをリクエストします。 認可サーバーはJWTを検証し、クライアント・アプリケーションにアクセス・トークンを発行します。 | はい | いいえ |
- Oracle Cloud Infrastructureドキュメントの「アクセス付与タイプ」。
- Oracle Identity Cloud ServiceのREST APIの「アクセス付与タイプ」。
許可コード付与タイプ(3-Legged OAuth)を使用したOAuthの構成
認可コード(3-legged OAuth)構成の場合、関係者は: ユーザー、アプリケーション、認可サーバー、およびリソース・サーバー。 ユーザーが認可を受けるには、アプリケーションを認可サーバー(この場合はFusion Applicationsアイデンティティ・ドメイン)に登録する必要があります。 したがって、複数のユーザーがアクセスできるが、OAuth資格証明を機密にして保護できる機密アプリケーションを作成する必要があります。 アプリケーションでこれを行う方法を見てみましょう。
- クライアントおよびリソース・アプリケーションを認可サーバーに登録します。
- Fusion Applicationsアイデンティティ・ドメインに管理者としてサインインします。
- アイデンティティ・ドメインのリストで、「統合アプリケーション」をクリックし、「アプリケーションの追加」をクリックします。
- 「アプリケーションの追加」ダイアログ・ボックスで、「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
- 「機密アプリケーションの追加」ページで、追加するアプリケーションの名前を入力します。
- URLセクションでは、フィールドはオプションとしてマークされていますが、必要と思われる詳細を追加できます。
- 設定を表示で、関連するオプションを選択します。
- 「認証および認可」セクションで、「権限付与を権限として強制」チェック・ボックスを選択して、ユーザーが以前にアクセス権を付与された場合にのみ機密アプリケーションへのアクセスを許可します。 それ以外の場合は、選択を解除したままにします。
- 「次」をクリックします。
- 「OAuthの構成」セクションで、「このアプリケーションをクライアントとして今すぐ構成」を選択してクライアント構成設定を続行します。
- 「許可」セクションで、「認証コード」チェック・ボックスを選択して付与タイプを指定します。
- 「リダイレクトURL」フィールドに値を入力します。 これは、認証後にユーザーが取得されるアプリケーションURL (認可コードにURLパラメータとして追加)です。
- 必要に応じて、ログアウトURLとログアウト後のURLを追加します。
- クライアント・アプリケーションのタイプを識別するには、「機密」をデフォルトの選択値として保持します。
- 適用可能な「許可」操作を選択します。 選択するオプションの詳細は、フィールド・レベルのヘルプを参照してください。 何も必要としない場合は、何も選択せずに続行できます。
- IDトークン暗号化アルゴリズムで、トークンを暗号化する必要があるかどうかを選択します。 デフォルト値は「なし」です。
- トグルを使用して、同意をバイパス機能を有効にします。 有効にすると、リソースがユーザーの同意を必要とするように構成されている場合でも、リソースに対するアクセス権がユーザーに付与される前に、リソースはリソース所有者の同意を必要としません。
- クライアントIPアドレスの関連オプションを選択します。 該当するものがない場合は、選択を解除したままにできます。
- トークン発行ポリシー・セクションで、ユーザーがすべてのリソースにアクセスする必要があるか、許可されているリソースのみにアクセスする必要があるかに基づいて、「すべて」または「具体的な」を選択します。
- 製品のリソースを追加します。
- 「リソースの追加」チェック・ボックスを選択して、ユーザーがアクセスできるリソースを含めます。
- 「リソース」サブセクションで、「スコープの追加」をクリックします。
- 「スコープの追加」ダイアログ・ボックスで、リソースを含むアプリケーションを選択し、「追加」をクリックします。 リソースが追加されます。 スコープは、次の形式で定義されています:
<resource audience name><resource scope name>
. - 追加されたリソースを確認します。 リソースが不要な場合は、「除去」を選択して、スコープから除外します。
- アプリケーションの作成とアクティブ化を完了します。
- リソースを追加したら、「次」をクリックし、「Web層ポリシー」セクションのデフォルト設定に従います。
- 「終了」をクリックします。 自動生成された「クライアントID」および「クライアント・シークレット」値を示す確認ダイアログ・ボックスが表示されます。 ノート: 「クライアントID」および「クライアント・シークレット」の値は、アクセス・トークンのリクエストに必要になるためノートにとります。
- 「クローズ」をクリックします。 作成したアプリケーション・ページが表示されます。
- 「アクティブ化」をクリックします。 アプリケーションをアクティブ化するための確認を求める確認メッセージが表示されます。
- 「アプリケーションのアクティブ化」をクリックします。 機密アプリケーションがアクティブ化され、すぐに使用できます。
- アクセス・トークンをリクエストします。 そのためには、PostmanやcURLコマンドなどのクライアント・アプリケーションを使用します。 これらの両方のオプションを見てみましょう。
Postmanの使用 cURLの使用 - Postmanで、新規リクエストを作成します。
- 「認可」タブで、「認可タイプ」としてOAuth 2.0を選択します。
- 「新規トークンの構成」セクションで、次のクライアント構成を入力します:
- トークン名: トークンの汎用名を入力します。
- 付与タイプ: 付与タイプを「承認コード」に設定します。
- コールバックURL: IDCSから収集されたリダイレクトURLの値を入力します。
- 「ブラウザを使用した認証」チェック・ボックスを選択して、ブラウザを介したトークンの生成を承認します。
- 認証URL: /oauth2/v1/authorizeが付加されたIDCS URLが認証URLとして使用されます。 URLは、https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationから取得できます。
- アクセス・トークンURL: /oauth2/v1/tokenが付加されたIDCS URLがアクセス・トークンURLとして使用されます。 URLは、https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationから取得できます。
- クライアントID: IDCSから収集されたクライアントID値を入力します。
- クライアント・シークレット: IDCSから収集されたクライアント・シークレット値を入力します。
- スコープ: アイデンティティ・ドメインに定義されているスコープを指定します。
- クライアント認証: 「基本認証ヘッダーとして送信」を選択します。
- 「新規アクセス・トークンの取得」をクリックします。 Postmanは、情報をアイデンティティ・ドメインに渡して認証し、アクセス・トークンを返します。
- ブラウザを開き、次のURLを使用して認可コードを取得するリクエストを送信します:
ブラウザは、機密アプリケーションで指定された<redirect URL>にリダイレクトされます。 URLパスでは、認可コードをパラメータとして検索できます。 ステップcで後で使用できるように認可コードをコピーします。https://<domainURL>/oauth2/v1/authorize?response_type=code&client_id=<clientid>&redirect_uri=<redirect url>&scope=<scope>
- コマンド・プロンプトを起動します。
- 次のcURLコマンドを入力して、山カッコ(< >)のテキストを適切な値に置き換えます:
curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=authorization_code&code=<authorization code>&redirect_uri=<redirect url>"
- 次のような形式でレスポンスを予想できます:
Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer", "expires_in":3600
access_token
に表示されている値をコピーします。 これは、リソースへのアクセスをリクエストする必要があるトークンです。
- アクセス・トークンを使用してリソースにアクセスします。 Postmanで、「トークンを使用」をクリックしてトークンを使用し(トークン・フィールドを自動入力)、リソース・サーバーからリソースにアクセスします。 または、前のステップでcURLコマンドを使用した場合は、コマンド・プロンプトを続行してRESTリクエストを送信し、リソースへのアクセス権を取得できます。 次のようにリクエストを構成する必要があります:
AuthorizationヘッダーがBearerトークンに設定されており、値として以前に取得したアクセス・トークンを指定することに注意してください。curl -X GET -H "Content-Type:<as needed by your REST endpoint, such as, application/json>" -H "Authorization: Bearer <access_token>" "https://<REST API endpoint URL>"
クライアント資格証明付与タイプ(2-legged OAuth)を使用したOAuthの構成
ユーザーの介入なしでリクエストを処理し、リクエストでユーザー権限を使用する必要がないアプリケーションを設定する場合は、「クライアント資格証明」付与タイプを使用して2-legged OAuthフローを設定できます。 このシナリオでは、クライアント資格証明がアプリケーション自体に格納されるため、認可サーバーはユーザーからのレスポンスを必要とせずにそれを検証できます。 通常、この設定は、自動化されたアプリケーション・レベルのリクエストを処理するクライアントとサーバーのやり取りに推奨されます。 アプリケーションでの設定方法を見てみましょう。
- ユーザーがリソースにアクセスできるようにするアプリケーションを作成します。
- 管理者としてアイデンティティ・ドメインにサインインします。
- アイデンティティ・ドメインのリストで、「統合アプリケーション」をクリックし、「アプリケーションの追加」をクリックします。
- 「アプリケーションの追加」ダイアログ・ボックスで、「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
- 「機密アプリケーションの追加」ページで、追加するアプリケーションの名前を入力します。
- URLセクションでは、フィールドはオプションとしてマークされていますが、必要と思われる詳細を追加できます。
- 設定を表示で、関連するオプションを選択します。
- 「認証および認可」セクションで、「権限付与を権限として強制」チェック・ボックスを選択して、ユーザーが以前にアクセス権を付与された場合にのみ機密アプリケーションへのアクセスを許可します。 それ以外の場合は、選択を解除したままにします。
- 「次」をクリックします。
- 「シングル・サインオンの構成」セクションで、「このアプリケーションをクライアントとして今すぐ構成」を選択してクライアント構成設定を続行します。
- 「許可」セクションで、「クライアント資格証明」チェック・ボックスを選択して付与タイプを指定します。
- 適用可能な「許可」操作を選択します。 選択するオプションの詳細は、フィールド・レベルのヘルプを参照してください。 何も必要としない場合は、何も選択せずに続行できます。
- IDトークン暗号化アルゴリズムで、トークンを暗号化する必要があるかどうかを選択します。 デフォルト値は「なし」です。
- クライアントIPアドレスの関連オプションを選択します。 該当するものがない場合は、選択を解除したままにできます。
- トークン発行ポリシー・セクションで、ユーザーがすべてのリソースにアクセスする必要があるか、許可されているリソースのみにアクセスする必要があるかに基づいて、「すべて」または「具体的な」を選択します。
- 製品のリソースを追加します。
- 「リソースの追加」チェック・ボックスを選択して、ユーザーがアクセスできるリソースを含めます。
- 「リソース」サブセクションで、「スコープの追加」をクリックします。
- 「スコープの追加」ダイアログ・ボックスで、リソースを含むアプリケーションを選択し、「追加」をクリックします。 リソースが追加されます。 スコープは、次の形式で定義されています:
<resource audience><resource scope>
. - 追加されたリソースを確認します。 リソースが不要な場合は、「除去」を選択して、スコープから除外します。
- アプリケーションの作成とアクティブ化を完了します。
- リソースを追加したら、「次」をクリックし、「Web層ポリシー」セクションのデフォルト設定に従います。
- 「終了」をクリックします。 自動生成された「クライアントID」および「クライアント・シークレット」値を示す確認ダイアログ・ボックスが表示されます。 ノート: 「クライアントID」および「クライアント・シークレット」の値は、アクセス・トークンのリクエストに必要になるためノートにとります。
- 「クローズ」をクリックします。 作成したアプリケーション・ページが表示されます。
- 「アクティブ化」をクリックします。 アプリケーションをアクティブ化するための確認を求める確認メッセージが表示されます。
- 「アプリケーションのアクティブ化」をクリックします。 機密アプリケーションがアクティブ化され、すぐに使用できます。
- アクセス・トークンをリクエストします。 これは、PostmanやcURLコマンドなどのクライアント・アプリケーションを使用して実行できます。 これらの両方のオプションを見てみましょう。
Postmanの使用 cURLの使用 - Postmanで、新規リクエストを作成します。
- 「認可」タブで、「認可タイプ」としてOAuth 2.0を選択します。
- 「新規トークンの構成」セクションで、次のクライアント構成を入力します:
- トークン名: トークンの汎用名を入力します。
- 付与タイプ: 「クライアント資格証明」を選択します。
- アクセス・トークンURL: /oauth2/v1/tokenが付加されたIDCS URLがアクセス・トークンURLとして使用されます。 URLは、https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationから取得できます。
- クライアントID: IDCSから収集されたクライアントID値を入力します。
- クライアント・シークレット: IDCSから収集されたクライアント・シークレット値を入力します。
- スコープ: アイデンティティ・ドメインに定義されているスコープを指定します。
- クライアント認証: 「基本認証ヘッダーとして送信」を選択します。
- 「新規アクセス・トークンの取得」をクリックします。 Postmanは、情報をアイデンティティ・ドメインに渡して認証し、アクセス・トークンを返します。
- コマンド・プロンプトを起動します。
- 次のcURLコマンドを入力して、山カッコ(< >)のテキストを適切な値に置き換えます:
curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=client_credentials&scope=<scope>"
- 次のような形式でレスポンスを予想できます:
Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer", "expires_in":3600
access_token
に表示されている値をコピーします。 これは、リソースへのアクセスをリクエストする必要があるトークンです。
- アクセス・トークンを使用してリソースにアクセスします。 Postmanで、「トークンを使用」をクリックしてトークンを使用し(トークン・フィールドを自動入力)、リソース・サーバーからリソースにアクセスします。 または、前のステップでcURLコマンドを使用した場合は、コマンド・プロンプトを続行してRESTリクエストを送信し、リソースへのアクセス権を取得できます。 次のようにリクエストを構成する必要があります:
AuthorizationヘッダーがBearerトークンに設定されており、値として以前に取得したアクセス・トークンを指定することに注意してください。curl -X GET -H "<as needed by your REST endpoint, such as application/json>" -H "Authorization: Bearer <access_token>" "https://<REST API endpoint URL>"
リソース所有者権限付与タイプ(2-legged OAuth)を使用したOAuthの構成
非常に安全で信頼性の高い環境で操作している場合は、「リソース所有者」権限付与タイプOAuthフローを使用できます。 このモデルでは、リソース所有者は、リクエストをアイデンティティ・プロバイダにリダイレクトするのではなく、クライアント・アプリケーションで直接リクエストを認証します。 クライアントは、認可サーバーに登録された信頼できるアプリケーションです。 認可サーバーは、リクエストを受信すると、リソース所有者の資格証明を検証し、アクセス・トークンをクライアントに返します。 アプリケーションでの設定方法を見てみましょう。
- ユーザーがリソースにアクセスできるようにするアプリケーションを作成します。
- 管理者としてアイデンティティ・ドメインにサインインします。
- アイデンティティ・ドメインのリストで、「統合アプリケーション」をクリックし、「アプリケーションの追加」をクリックします。
- 「アプリケーションの追加」ダイアログ・ボックスで、「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
- 「機密アプリケーションの追加」ページで、追加するアプリケーションの名前を入力します。
- URLセクションでは、フィールドはオプションとしてマークされていますが、必要と思われる詳細を追加できます。
- 設定を表示で、関連するオプションを選択します。
- 「認証および認可」セクションで、「権限付与を権限として強制」チェック・ボックスを選択して、ユーザーが以前にアクセス権を付与された場合にのみ機密アプリケーションへのアクセスを許可します。 それ以外の場合は、選択を解除したままにします。
- 「次」をクリックします。
- 「シングル・サインオンの構成」セクションで、「このアプリケーションをクライアントとして今すぐ構成」を選択してクライアント構成設定を続行します。
- 「許可」セクションで、「リソース所有者」チェック・ボックスを選択して付与タイプを指定します。
- 適用可能な「許可」操作を選択します。 選択するオプションの詳細は、フィールド・レベルのヘルプを参照してください。 何も必要としない場合は、何も選択せずに続行できます。
- IDトークン暗号化アルゴリズムで、トークンを暗号化する必要があるかどうかを選択します。 デフォルト値は「なし」です。
- トグルを使用して、同意をバイパス機能を有効にします。 有効にすると、リソースに対するアクセス権がユーザーに付与される前に、リソースはリソース所有者の同意を必要としません。
- クライアントIPアドレスの関連オプションを選択します。 該当するものがない場合は、選択を解除したままにできます。
- トークン発行ポリシー・セクションで、ユーザーがすべてのリソースにアクセスする必要があるか、許可されているリソースのみにアクセスする必要があるかに基づいて、「すべて」または「具体的な」を選択します。
- 製品のリソースを追加します。
- 「リソースの追加」チェック・ボックスを選択して、ユーザーがアクセスできるリソースを含めます。
- 「リソース」サブセクションで、「スコープの追加」をクリックします。
- 「スコープの追加」ダイアログ・ボックスで、リソースを含むアプリケーションを選択し、「追加」をクリックします。 リソースが追加されます。 スコープは、次の形式で定義されています:
<resource audience name><resource scope name>
. - 追加されたリソースを確認します。 リソースが不要な場合は、「除去」を選択して、スコープから除外します。
- アプリケーションの作成とアクティブ化を完了します。
- リソースを追加したら、「次」をクリックし、「Web層ポリシー」セクションのデフォルト設定に従います。
- 「終了」をクリックします。 自動生成された「クライアントID」および「クライアント・シークレット」値を示す確認ダイアログ・ボックスが表示されます。 ノート: 「クライアントID」および「クライアント・シークレット」の値は、アクセス・トークンのリクエストに必要になるためノートにとります。
- 「クローズ」をクリックします。 作成したアプリケーション・ページが表示されます。
- 「アクティブ化」をクリックします。 アプリケーションをアクティブ化するための確認を求める確認メッセージが表示されます。
- 「アプリケーションのアクティブ化」をクリックします。 機密アプリケーションがアクティブ化され、すぐに使用できます。
- アクセス・トークンをリクエストします。 これは、PostmanやcURLコマンドなどのクライアント・アプリケーションを使用して実行できます。 これらの両方のオプションを見てみましょう。
Postmanの使用 cURLの使用 - Postmanで、新規リクエストを作成します。
- 「認可」タブで、「認可タイプ」としてOAuth 2.0を選択します。
- 「新規トークンの構成」セクションで、次のクライアント構成を入力します:
- トークン名: トークンの汎用名を入力します。
- 付与タイプ: 「パスワード資格証明」を選択します。
- アクセス・トークンURL: /oauth2/v1/tokenが付加されたIDCS URLがアクセス・トークンURLとして使用されます。 URLは、https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationから取得できます。
- クライアントID: IDCSから収集されたクライアントID値を入力します。
- クライアント・シークレット: IDCSから収集されたクライアント・シークレット値を入力します。
- ユーザー名: ユーザー名を入力します。
- パスワード: ユーザーのパスワードを入力します。
- スコープ: アイデンティティ・ドメインに定義されているスコープを指定します。
- クライアント認証: 「基本認証ヘッダーとして送信」を選択します。
- 「新規アクセス・トークンの取得」をクリックします。 Postmanは、情報をアイデンティティ・ドメインに渡して認証し、アクセス・トークンを返します。
- コマンド・プロンプトを起動します。
- 次のcURLコマンドを入力して、山カッコ(< >)のテキストを適切な値に置き換えます:
curl -u <clientid:clientsecret> --basic -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=password&username=<username>&password=<password>&scope=<scope>"
- 次のような形式でレスポンスを予想できます:
Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer", "expires_in":3600
access_token
に表示されている値をコピーします。 これは、リソースへのアクセスをリクエストする必要があるトークンです。
- アクセス・トークンを使用してリソースにアクセスします。Postmanで、「トークンを使用」をクリックしてトークンを使用し(トークン・フィールドを自動入力)、リソース・サーバーからリソースにアクセスします。 または、前のステップでcURLコマンドを使用した場合は、コマンド・プロンプトを続行してRESTリクエストを送信し、リソースへのアクセス権を取得できます。 次のようにリクエストを構成する必要があります:
AuthorizationヘッダーがBearerトークンに設定されており、値として以前に取得したアクセス・トークンを指定することに注意してください。curl -X GET -H "<as needed by your REST endpoint, such as application/json>" -H "Authorization: Bearer <access_token>" "https://<REST API endpoint URL>"