Fusion Applicationsアイデンティティ・ドメインを使用したOAuthの構成
Oracle ApplicationsのコンテキストでOAuthは、自動生成されたトークン(JWTとも呼ばれるJSON Webトークン)を使用して、必要なリソースへのアクセス権を付与します。 そのトークンを取得するプロセスには、いくつかのステップが含まれます。 このトピックでは、設定全体の理解に役立つ説明内容とともに、構成手順について説明します。
Fusion Applicationsインスタンスに関連付けられたOracle Cloud Infrastructure Identity and Access Management (IAM)アイデンティティ・ドメインを使用して、OAuthフローを構成します。 Fusion Applicationのすべてのユーザーは、同期を介して自動的にFusion IAMドメインで使用でき、拡張がFusion Applications REST APIにアクセスするリクエストを送信すると、OAuthを使用できます。
さらに進む前に
OAuthの構成では、Oracle Cloud Infrastructure Identity and Access Managementをよく理解し、アイデンティティ・ドメインの作成とメンテナンスの経験があることが必要です。 詳細は、「IAMの概要」を参照してください。
- 機密アプリケーションを作成するアイデンティティ・ドメインを特定します。 ドメインは認可サーバーになります。 ノート: 自分または他の必須ユーザーが、アイデンティティ・ドメインに移動するためにIdentity and Access Management管理コンソールにアクセスするために必要な権限を持っていることを確認します。 詳細は、「ユーザーの管理」を参照してください。
- OAuthフローを決定する付与タイプを指定します。 要件に基づいて、2-legged OAuthまたは3-legged OAuthを構成できます。
- アクセスの範囲を定義します。
- アクセス・トークンを生成します。
- トークンを使用してRESTリソースにアクセスします。
2脚のOAuthと3脚の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資格証明を機密にして保護できる機密アプリケーションを作成する必要があります。 アプリケーションでこれを行う方法を見てみましょう。
この手順では、構成に不可欠なフィールドおよびデータ入力ポイントのみに焦点を当てます。 ここに記載されていないUI上の他のフィールドは無視してスキップできます。 関連する場合、フィールドをスキップする手順が手順に含まれます。
- クライアントおよびリソース・アプリケーションを認可サーバーに登録します。
- Fusion Applicationsアイデンティティ・ドメインに管理者としてサインインします。
- アイデンティティ・ドメインのリストで、「統合アプリケーション」をクリックし、「アプリケーションの追加」をクリックします。
- 「アプリケーションの追加」ダイアログ・ボックスで、「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
- 「機密アプリケーションの追加」ページで、追加するアプリケーションの名前を入力します。
- その他すべてのフィールドをスキップし、「次」をクリックします。
- 「OAuthの構成」セクションで、「このアプリケーションをクライアントとして今すぐ構成」を選択してクライアント構成設定を続行します。 クライアント・アプリケーションを作成しているため、このオプションのみが関連します。
- 「許可」セクションで、「認証コード」チェック・ボックスを選択して付与タイプを指定します。 これは、このフローに必要な唯一の付与タイプです。
- 「リダイレクトURL」フィールドに、Fusion Applications RESTリソースへのアクセスを必要とするカスタム・アプリケーションのURLを入力します。ノート: URLパスは、アプリケーションのタイプによって異なる場合があります。 OAuth構成に使用されるリダイレクトURLに関する正確な情報は、カスタム・アプリケーションのドキュメントを参照してください。
- 次のいくつかのフィールドをスキップして、トークン発行ポリシー・セクションに移動します。
- 「許可されたリソース」で、「具体的な」を選択して、ユーザーに特定のリソースのみへのアクセス権が付与されるようにします。
- 製品のリソースを追加します。
- 「リソースの追加」チェック・ボックスを選択して、ユーザーがアクセスできるリソースを含めます。
- 「リソース」サブセクションで、「スコープの追加」をクリックします。ヒント: スコープによって、アプリケーションのリソースに対するアクセスのレベルが決まります。 リソース・アプリケーション管理者によって定義されます。 スコープを検索するには、ドメインに移動し、Fusion ApplicationsなどのOracleプロビジョニング・リソース・アプリケーションを探します。 サービスの詳細ページで、セクションに移動します。 表にスコープが表示されます。
- 「スコープの追加」ダイアログ・ボックスで、リソースを含むアプリケーションを選択し、「追加」をクリックします。 リソースが追加されます。 スコープは、次の形式で定義されています:
<resource audience name><resource scope name>. - 追加されたリソースを確認します。 リソースが不要な場合は、「除去」を選択して、スコープから除外します。
- アプリケーションの作成とアクティブ化を完了します。
- リソースを追加したら、「次」をクリックし、「Web層ポリシー」セクションのデフォルト設定に従います。 このページの設定を変更する必要はありません。
- 「終了」をクリックします。 自動生成された「クライアントID」および「クライアント・シークレット」値を示す確認ダイアログ・ボックスが表示されます。 ノート: 「クライアントID」および「クライアント・シークレット」の値は、アクセス・トークンのリクエストに必要になるためノートにとります。
- 「クローズ」をクリックします。 作成したアプリケーション・ページが表示されます。
- 「アクティブ化」をクリックします。 アプリケーションをアクティブ化するための確認を求める確認メッセージが表示されます。
- 「アプリケーションのアクティブ化」をクリックします。 機密アプリケーションがアクティブ化され、すぐに使用できます。
- アクセス・トークンをリクエストします。 そのためには、PostmanやcURLコマンドなどのクライアント・アプリケーションを使用します。 これらの両方のオプションを見てみましょう。
Postmanの使用 cURLの使用 - Postmanで、新規リクエストを作成します。
- 「認可」タブで、「認可タイプ」としてOAuth 2.0を選択します。
- 「新規トークンの構成」セクションで、次のクライアント構成を入力します:
- トークン名: トークンの汎用名を入力します。
- 付与タイプ: 付与タイプを「承認コード」に設定します。
- コールバックURL: アイデンティティ・ドメインに入力された「リダイレクトURL」の値を入力します。ノート: URL値が機密アプリケーションで構成されているものと一致していることを確認してください。
- 「ブラウザを使用した認証」チェック・ボックスを選択して、ブラウザを介したトークンの生成を承認します。 このオプションを選択すると、認証後、ブラウザにアプリケーションURLに追加された認可コードが表示されます。
- 認証URL: /oauth2/v1/authorizeが付加されたURLが認証URLとして使用されます。 https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationからURLを取得できます。
- アクセス・トークンURL: /oauth2/v1/tokenが付加されたURLがアクセス・トークンURLとして使用されます。 https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationからURLを取得できます。
- クライアントID: 機密アプリケーションの作成後に自動生成されたクライアントID値を入力します。
- クライアント・シークレット: 機密アプリケーションの作成後に自動生成された「クライアント・シークレット」の値を入力します。
- スコープ: アイデンティティ・ドメインに定義されているスコープを指定します。
- クライアント認証: 「基本認証ヘッダーとして送信」を選択します。
- 「新規アクセス・トークンの取得」をクリックします。 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フローを設定できます。 このシナリオでは、クライアント資格証明がアプリケーション自体に格納されるため、認可サーバーはユーザーからのレスポンスを必要とせずにそれを検証できます。 通常、この設定は、自動化されたアプリケーション・レベルのリクエストを処理するクライアントとサーバーのやり取りに推奨されます。 アプリケーションでの設定方法を見てみましょう。
この手順では、構成に不可欠なフィールドおよびデータ入力ポイントのみに焦点を当てます。 ここに記載されていないUI上の他のフィールドは無視してスキップできます。 関連する場合、フィールドをスキップする手順が手順に含まれます。
- ユーザーがリソースにアクセスできるようにするアプリケーションを作成します。
- 管理者としてアイデンティティ・ドメインにサインインします。
- アイデンティティ・ドメインのリストで、「統合アプリケーション」をクリックし、「アプリケーションの追加」をクリックします。
- 「アプリケーションの追加」ダイアログ・ボックスで、「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
- 「機密アプリケーションの追加」ページで、追加するアプリケーションの名前を入力します。
- その他すべてのフィールドをスキップし、「次」をクリックします。
- 「シングル・サインオンの構成」セクションで、「このアプリケーションをクライアントとして今すぐ構成」を選択してクライアント構成設定を続行します。 クライアント・アプリケーションを作成しているため、このオプションのみが関連します。
- 「許可」セクションで、「クライアント資格証明」チェック・ボックスを選択して付与タイプを指定します。
- 次のいくつかのフィールドをスキップして、トークン発行ポリシー・セクションに移動します。
- 「許可されたリソース」で、「具体的な」を選択して、ユーザーに特定のリソースのみへのアクセス権が付与されるようにします。
- 製品のリソースを追加します。
- 「リソースの追加」チェック・ボックスを選択して、ユーザーがアクセスできるリソースを含めます。
- 「リソース」サブセクションで、「スコープの追加」をクリックします。
- 「スコープの追加」ダイアログ・ボックスで、リソースを含むアプリケーションを選択し、「追加」をクリックします。 リソースが追加されます。 スコープは、次の形式で定義されています:
<resource audience><resource scope>. - 追加されたリソースを確認します。 リソースが不要な場合は、「除去」を選択して、スコープから除外します。
- アプリケーションの作成とアクティブ化を完了します。
- リソースを追加したら、「次」をクリックし、「Web層ポリシー」セクションのデフォルト設定に従います。 このページの設定を変更する必要はありません。
- 「終了」をクリックします。 自動生成された「クライアントID」および「クライアント・シークレット」値を示す確認ダイアログ・ボックスが表示されます。 ノート: 「クライアントID」および「クライアント・シークレット」の値は、アクセス・トークンのリクエストに必要になるためノートにとります。 また、セキュリティ・コンソールを使用して、クライアントIDをFusion Applicationsのユーザーとして構成することを忘れないでください。 ユーザー名が自動生成されたクライアントIDと同じであることを確認してください。 相違があると、構成が失敗する可能性があります。
- 「クローズ」をクリックします。 作成したアプリケーション・ページが表示されます。
- 「アクティブ化」をクリックします。 アプリケーションをアクティブ化するための確認を求める確認メッセージが表示されます。
- 「アプリケーションのアクティブ化」をクリックします。 機密アプリケーションがアクティブ化され、すぐに使用できます。
- アクセス・トークンをリクエストします。 これは、PostmanやcURLコマンドなどのクライアント・アプリケーションを使用して実行できます。 これらの両方のオプションを見てみましょう。
Postmanの使用 cURLの使用 - Postmanで、新規リクエストを作成します。
- 「認可」タブで、「認可タイプ」としてOAuth 2.0を選択します。
- 「新規トークンの構成」セクションで、次のクライアント構成を入力します:
- トークン名: トークンの汎用名を入力します。
- 付与タイプ: 「クライアント資格証明」を選択します。
- アクセス・トークンURL: /oauth2/v1/tokenが付加されたURLがアクセス・トークンURLとして使用されます。 https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationからURLを取得できます。
- クライアントID: 機密アプリケーションの作成後に自動生成されたクライアントID値を入力します。
- クライアント・シークレット: 機密アプリケーションの作成後に自動生成された「クライアント・シークレット」の値を入力
- スコープ: アイデンティティ・ドメインに定義されているスコープを指定します。
- クライアント認証: 「基本認証ヘッダーとして送信」を選択します。
- 「新規アクセス・トークンの取得」をクリックします。 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フローを使用できます。 このモデルでは、リソース所有者は、リクエストをアイデンティティ・プロバイダにリダイレクトするのではなく、クライアント・アプリケーションで直接リクエストを認証します。 クライアントは、認可サーバーに登録された信頼できるアプリケーションです。 認可サーバーは、リクエストを受信すると、リソース所有者の資格証明を検証し、アクセス・トークンをクライアントに返します。 アプリケーションでの設定方法を見てみましょう。
この手順では、構成に不可欠なフィールドおよびデータ入力ポイントのみに焦点を当てます。 ここに記載されていないUI上の他のフィールドは無視してスキップできます。 関連する場合、フィールドをスキップする手順が手順に含まれます。
- ユーザーがリソースにアクセスできるようにするアプリケーションを作成します。
- 管理者としてアイデンティティ・ドメインにサインインします。
- アイデンティティ・ドメインのリストで、「統合アプリケーション」をクリックし、「アプリケーションの追加」をクリックします。
- 「アプリケーションの追加」ダイアログ・ボックスで、「機密アプリケーション」を選択し、「ワークフローの起動」をクリックします。
- 「機密アプリケーションの追加」ページで、追加するアプリケーションの名前を入力します。
- その他すべてのフィールドをスキップし、「次」をクリックします。
- 「シングル・サインオンの構成」セクションで、「このアプリケーションをクライアントとして今すぐ構成」を選択してクライアント構成設定を続行します。 クライアント・アプリケーションを作成しているため、このオプションのみが関連します。
- 「許可」セクションで、「リソース所有者」チェック・ボックスを選択して付与タイプを指定します。
- 次のいくつかのフィールドをスキップして、トークン発行ポリシー・セクションに移動します。
- 「許可されたリソース」セクションで、「具体的な」を選択して、ユーザーに特定のリソースのみへのアクセス権が付与されるようにします。
- 製品のリソースを追加します。
- 「リソースの追加」チェック・ボックスを選択して、ユーザーがアクセスできるリソースを含めます。
- 「リソース」サブセクションで、「スコープの追加」をクリックします。
- 「スコープの追加」ダイアログ・ボックスで、リソースを含むアプリケーションを選択し、「追加」をクリックします。 リソースが追加されます。 スコープは、次の形式で定義されています:
<resource audience name><resource scope name>. - 追加されたリソースを確認します。 リソースが不要な場合は、「除去」を選択して、スコープから除外します。
- アプリケーションの作成とアクティブ化を完了します。
- リソースを追加したら、「次」をクリックし、「Web層ポリシー」セクションのデフォルト設定に従います。 このページの設定を変更する必要はありません。
- 「終了」をクリックします。 自動生成された「クライアントID」および「クライアント・シークレット」値を示す確認ダイアログ・ボックスが表示されます。 ノート: 「クライアントID」および「クライアント・シークレット」の値は、アクセス・トークンのリクエストに必要になるためノートにとります。
- 「クローズ」をクリックします。 作成したアプリケーション・ページが表示されます。
- 「アクティブ化」をクリックします。 アプリケーションをアクティブ化するための確認を求める確認メッセージが表示されます。
- 「アプリケーションのアクティブ化」をクリックします。 機密アプリケーションがアクティブ化され、すぐに使用できます。
- アクセス・トークンをリクエストします。 これは、PostmanやcURLコマンドなどのクライアント・アプリケーションを使用して実行できます。 これらの両方のオプションを見てみましょう。
Postmanの使用 cURLの使用 - Postmanで、新規リクエストを作成します。
- 「認可」タブで、「認可タイプ」としてOAuth 2.0を選択します。
- 「新規トークンの構成」セクションで、次のクライアント構成を入力します:
- トークン名: トークンの汎用名を入力します。
- 付与タイプ: 「パスワード資格証明」を選択します。
- アクセス・トークンURL: /oauth2/v1/tokenが付加されたURLがアクセス・トークンURLとして使用されます。 https://idcs-<idcs-id>.identity.oraclecloud.com/.well-known/idcs-configurationからURLを取得できます。
- クライアントID: 機密アプリケーションの作成後に自動生成されたクライアントID値を入力します。
- クライアント・シークレット: 機密アプリケーションの作成後に自動生成された「クライアント・シークレット」の値を入力します。
- ユーザー名: ユーザー名を入力します。
- パスワード: ユーザーのパスワードを入力します。
- スコープ: アイデンティティ・ドメインに定義されているスコープを指定します。
- クライアント認証: 「基本認証ヘッダーとして送信」を選択します。
- 「新規アクセス・トークンの取得」をクリックします。 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>"