OAuth 2.0の付与について

機械翻訳について

OAuth 2.0の付与について

Oracle Integrationで使用できるOAuth 2.0付与タイプがいくつかあります。次の情報を確認して、ユースケースに使用する権限付与タイプを特定します。

権限付与タイプ権限付与タイプについてユースケースとリスク

権限付与タイプ	権限付与タイプについて	ユースケースとリスク
JWTユーザー・アサーション (推奨)	ユーザー・アサーションとは、ユーザーに関するアイデンティティ情報を含むユーザー・トークンです。ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。ユーザー・アサーションは、アクセス・トークンを取得するための許可付与として直接使用されます。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。ユーザーの資格証明は公開されないため、ユーザー・アサーションの付与はリソース所有者のパスワード資格証明の付与よりも安全です。ユーザー・アサーション・ワークフロー: 機密クライアントとともに使用されます。 OAuthクライアントは、ユーザー/サービス統合アカウントのかわりにユーザー/サービス統合アカウント・アイデンティティをアサートすることが信頼されます。リソース所有者資格証明(Oracle Integrationユーザー)は、クライアント・アプリケーションからアクセスできません。リソース所有者のアサーションのみを使用します。リダイレクション・ベースではありません。クライアント・アプリケーションから認可サーバーへのリクエストのみを受け取ります。ユーザーは、リクエストを認可するためにインタフェース間でリダイレクトされません。このユーザー・アサーション権限付与は、次のように機能します: クライアントでは、ユーザー・アサーションを指定することによって、アクセス・トークンをリクエストします。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。 OAuthサービスはクライアントを認証し、有効な場合はアクセス・トークンを提供します。 JWTユーザー・アサーションの特性は次のとおりです: クライアントにユーザー資格証明の知識は必要ありません。ブラウザベースのエンドユーザー操作はありません。リフレッシュ・トークンが許可されます。アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。このOAuthフローは次のとおりです。ユーザーは、生成されたユーザー・アサーションを送信してクライアント・アプリケーションにアクセスしようとします。クライアント・アプリケーションは、ユーザー・アサーションまたはサード・パーティのユーザー・アサーションを提供することで、アクセス・トークン(多くの場合はリフレッシュ・トークン)をリクエストします。 Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	この権限付与は、ユーザーの介入なしで統合をプログラムで起動するアプリケーションで使用されます。クライアント・アプリケーションは、トークン・アクセスのリクエスト中にユーザー・アサーションをOracle Identity Cloud Serviceに送信することで、ユーザーを偽装します。ユーザー・コンテキストでアクセス・トークンが返されます。ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。 Oracle Integrationでは、ユーザーの介入なしで統合をプログラム的に開始する必要があるアプリケーションによるOAuthアクセス・トークンを取得するために、この付与の使用をお薦めします。リスク (ファースト・パーティ/信頼できるクライアントでのみ)この権限付与を慎重に使用してください。これは、サービスに対するより高度な権限のあるアカウントに対する簡易的な偽装を可能にするためです。使用状況「JWTユーザー・アサーションの前提条件」を参照してください。
認可コード	許可コード権限付与タイプは、webおよびモバイル・アプリケーションで使用されます。他のほとんどの権限付与タイプとは異なり、最初にアプリケーションでブラウザを起動して統合を開始する必要があります。高レベルでは、統合は次のステップで構成されます: ブラウザが開き、ユーザーがOAuthサーバーに送信されます。ユーザーに認可プロンプトが表示され、アプリケーション・リクエストが承認されます。ユーザーは、問合せ文字列に認可コードが含まれるアプリケーションにリダイレクトされます。アプリケーションは、認可コードをアクセス・トークンと交換します。認可コードには、次の特性があります: クライアントにユーザー資格証明の知識は必要ありません。ブラウザベースのエンド・ユーザー操作です。リフレッシュ・トークンが許可されます。アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。このOAuthフローは次のとおりです。ユーザーがwebサーバー・クライアント・アプリケーションのリンクをクリックして、保護されたリソースへのアクセスをリクエストします。クライアント・アプリケーションは、認可コードのリクエストを使用して、ブラウザをOracle Identity Cloud Service認可エンドポイントにリダイレクトします: `oauth2/v1/authorize` 　 Oracle Identity Cloud Service認可サーバーは、リソース所有者が同意を付与した後にブラウザ・リダイレクトを介してクライアント・アプリケーションに認可コードを返します。次に、クライアント・アプリケーションは、認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークンとともに)と交換します。　 Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	この権限は、統合を起動する可能性があるユーザー操作を含むwebポータルやモバイル・アプリケーションなどのアプリケーションで使用されます。このタイプのユースケースでは、ユーザーがwebポータル/モバイル・アプリケーションにサインインすると、Oracle Integrationに対して認証してアプリケーションが統合を開始できるようにすることで、同意が明示的に提供されます。使用状況「認証コードの前提条件」を参照してください。
リソース所有者のパスワード資格証明(ROPC)	アクセス・トークンを取得するための認可付与として、OAuthクライアントがリソース所有者のパスワード資格証明(つまり、ユーザー名とパスワード)を直接使用できます。リソース所有者のパスワード資格証明権限付与タイプは、リソース所有者がOAuthクライアントと信頼関係を持つ場合に適しています。リソース所有者のパスワード資格証明の付与を使用する場合、ユーザーが資格証明(ユーザー名とパスワード)を直接アプリケーションに指定します。次に、アプリケーションが資格証明を使用して、OAuthトークン・サービスからアクセス・トークンを取得します。リソース所有者のパスワード資格証明の付与は、クライアント・アプリケーションがそのクライアント識別子およびシークレットとともにユーザー名とパスワードを送信して、アクセス・トークンと交換する付与ワークフローです。ユーザーは、webインタフェースでログインして認可リクエストを承認するかわりに、クライアント・アプリケーション・ユーザー・インタフェースでユーザー名とパスワードを直接入力できます。このワークフローには、他のOAuthワークフローとは異なるセキュリティ・プロパティがあります。主な違いは、アプリケーションからユーザーのパスワードにアクセスできることです。このことは、アプリケーションに対するユーザーの強い信頼を必要とします。リソース所有者のパスワード資格証明の付与には、次の特性があります: クライアントには、ユーザー資格証明に関する知識が必要です。ブラウザベースのエンド・ユーザー操作ではありません。リフレッシュ・トークンが許可されます。アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。このOAuthフローは次のとおりです。ユーザーは、保護されたリソースへのアクセスをリクエストするクライアント・アプリケーション内のリンクをクリックします。クライアント・アプリケーションは、リソース所有者のユーザー名とパスワードをリクエストします。ユーザーは自分のユーザー名とパスワードでログインします。クライアント・アプリケーションは、これらの資格証明をOracle Identity Cloud Service認可サーバーからアクセス・トークン(通常はリフレッシュ・トークン)と交換します。 Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	この権限付与は、ユーザーの介入なしでプログラムによって統合を起動するアプリケーションで使用できます。この権限は、ユーザー資格証明を安全に処理する信頼できるファースト・パーティのクライアントでのみ使用します。この権限付与タイプは、クライアント・アプリケーションでOAuthアクセス・トークンを取得して、プログラム的な方法で統合を起動するリクエストを送信するために使用できますが、Oracle Integrationは、次のリスクのためにリソース所有者のパスワード資格証明の付与を推奨しません: リスクこの権限付与タイプは、このプロトコルが回避するために検索するパスワード・アンチ・パターンを保持するため、他の権限付与タイプよりもリスクが高くなります。クライアントがパスワードを不正に使用したり、パスワードが攻撃者に誤って公開される可能性があります(たとえば、ログ・ファイルやクライアントによって保持されているその他のレコードを介して)。アプリケーションは、パスワード資格証明を取得すると、ユーザー・リソースへの完全なアクセス権を持つスコープをリクエストできます。パスワードの有効期限が切れます。この権限は現在非推奨の状態です。使用状況「リソース所有者のパスワード資格証明の前提条件」を参照してください。

JWTユーザー・アサーション

(推奨)

ユーザー・アサーションとは、ユーザーに関するアイデンティティ情報を含むユーザー・トークンです。ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。

ユーザー・アサーションは、アクセス・トークンを取得するための許可付与として直接使用されます。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。

ユーザーの資格証明は公開されないため、ユーザー・アサーションの付与はリソース所有者のパスワード資格証明の付与よりも安全です。

ユーザー・アサーション・ワークフロー:

機密クライアントとともに使用されます。 OAuthクライアントは、ユーザー/サービス統合アカウントのかわりにユーザー/サービス統合アカウント・アイデンティティをアサートすることが信頼されます。
リソース所有者資格証明(Oracle Integrationユーザー)は、クライアント・アプリケーションからアクセスできません。リソース所有者のアサーションのみを使用します。
リダイレクション・ベースではありません。クライアント・アプリケーションから認可サーバーへのリクエストのみを受け取ります。ユーザーは、リクエストを認可するためにインタフェース間でリダイレクトされません。

このユーザー・アサーション権限付与は、次のように機能します:

クライアントでは、ユーザー・アサーションを指定することによって、アクセス・トークンをリクエストします。クライアント詳細は、リクエスト内の認証ヘッダーまたはクライアント・アサーションとして指定されます。
OAuthサービスはクライアントを認証し、有効な場合はアクセス・トークンを提供します。

JWTユーザー・アサーションの特性は次のとおりです:

クライアントにユーザー資格証明の知識は必要ありません。
ブラウザベースのエンドユーザー操作はありません。
リフレッシュ・トークンが許可されます。
アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。

このOAuthフローは次のとおりです。

ユーザーは、生成されたユーザー・アサーションを送信してクライアント・アプリケーションにアクセスしようとします。
クライアント・アプリケーションは、ユーザー・アサーションまたはサード・パーティのユーザー・アサーションを提供することで、アクセス・トークン(多くの場合はリフレッシュ・トークン)をリクエストします。
Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。
クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。

この権限付与は、ユーザーの介入なしで統合をプログラムで起動するアプリケーションで使用されます。

クライアント・アプリケーションは、トークン・アクセスのリクエスト中にユーザー・アサーションをOracle Identity Cloud Serviceに送信することで、ユーザーを偽装します。ユーザー・コンテキストでアクセス・トークンが返されます。

ユーザーは、特定のコール元アプリケーションを識別するために作成された人間またはサービス統合アカウントを表すことができます。

Oracle Integrationでは、ユーザーの介入なしで統合をプログラム的に開始する必要があるアプリケーションによるOAuthアクセス・トークンを取得するために、この付与の使用をお薦めします。

リスク

(ファースト・パーティ/信頼できるクライアントでのみ)この権限付与を慎重に使用してください。これは、サービスに対するより高度な権限のあるアカウントに対する簡易的な偽装を可能にするためです。

使用状況

「JWTユーザー・アサーションの前提条件」を参照してください。

認可コード

許可コード権限付与タイプは、webおよびモバイル・アプリケーションで使用されます。他のほとんどの権限付与タイプとは異なり、最初にアプリケーションでブラウザを起動して統合を開始する必要があります。高レベルでは、統合は次のステップで構成されます:

ブラウザが開き、ユーザーがOAuthサーバーに送信されます。
ユーザーに認可プロンプトが表示され、アプリケーション・リクエストが承認されます。
ユーザーは、問合せ文字列に認可コードが含まれるアプリケーションにリダイレクトされます。
アプリケーションは、認可コードをアクセス・トークンと交換します。

認可コードには、次の特性があります:

クライアントにユーザー資格証明の知識は必要ありません。
ブラウザベースのエンド・ユーザー操作です。
リフレッシュ・トークンが許可されます。
アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。

このOAuthフローは次のとおりです。

ユーザーがwebサーバー・クライアント・アプリケーションのリンクをクリックして、保護されたリソースへのアクセスをリクエストします。
クライアント・アプリケーションは、認可コードのリクエストを使用して、ブラウザをOracle Identity Cloud Service認可エンドポイントにリダイレクトします:
```
oauth2/v1/authorize
```
　
Oracle Identity Cloud Service認可サーバーは、リソース所有者が同意を付与した後にブラウザ・リダイレクトを介してクライアント・アプリケーションに認可コードを返します。
次に、クライアント・アプリケーションは、認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークンとともに)と交換します。
　
Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。
クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。

この権限は、統合を起動する可能性があるユーザー操作を含むwebポータルやモバイル・アプリケーションなどのアプリケーションで使用されます。このタイプのユースケースでは、ユーザーがwebポータル/モバイル・アプリケーションにサインインすると、Oracle Integrationに対して認証してアプリケーションが統合を開始できるようにすることで、同意が明示的に提供されます。

使用状況

「認証コードの前提条件」を参照してください。

リソース所有者のパスワード資格証明(ROPC)

アクセス・トークンを取得するための認可付与として、OAuthクライアントがリソース所有者のパスワード資格証明(つまり、ユーザー名とパスワード)を直接使用できます。

リソース所有者のパスワード資格証明権限付与タイプは、リソース所有者がOAuthクライアントと信頼関係を持つ場合に適しています。

リソース所有者のパスワード資格証明の付与を使用する場合、ユーザーが資格証明(ユーザー名とパスワード)を直接アプリケーションに指定します。次に、アプリケーションが資格証明を使用して、OAuthトークン・サービスからアクセス・トークンを取得します。

リソース所有者のパスワード資格証明の付与は、クライアント・アプリケーションがそのクライアント識別子およびシークレットとともにユーザー名とパスワードを送信して、アクセス・トークンと交換する付与ワークフローです。ユーザーは、webインタフェースでログインして認可リクエストを承認するかわりに、クライアント・アプリケーション・ユーザー・インタフェースでユーザー名とパスワードを直接入力できます。このワークフローには、他のOAuthワークフローとは異なるセキュリティ・プロパティがあります。主な違いは、アプリケーションからユーザーのパスワードにアクセスできることです。このことは、アプリケーションに対するユーザーの強い信頼を必要とします。

リソース所有者のパスワード資格証明の付与には、次の特性があります:

クライアントには、ユーザー資格証明に関する知識が必要です。
ブラウザベースのエンド・ユーザー操作ではありません。
リフレッシュ・トークンが許可されます。
アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。

このOAuthフローは次のとおりです。

ユーザーは、保護されたリソースへのアクセスをリクエストするクライアント・アプリケーション内のリンクをクリックします。
クライアント・アプリケーションは、リソース所有者のユーザー名とパスワードをリクエストします。
ユーザーは自分のユーザー名とパスワードでログインします。
クライアント・アプリケーションは、これらの資格証明をOracle Identity Cloud Service認可サーバーからアクセス・トークン(通常はリフレッシュ・トークン)と交換します。
Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。
クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。

この権限付与は、ユーザーの介入なしでプログラムによって統合を起動するアプリケーションで使用できます。

この権限は、ユーザー資格証明を安全に処理する信頼できるファースト・パーティのクライアントでのみ使用します。

この権限付与タイプは、クライアント・アプリケーションでOAuthアクセス・トークンを取得して、プログラム的な方法で統合を起動するリクエストを送信するために使用できますが、Oracle Integrationは、次のリスクのためにリソース所有者のパスワード資格証明の付与を推奨しません:

リスク

この権限付与タイプは、このプロトコルが回避するために検索するパスワード・アンチ・パターンを保持するため、他の権限付与タイプよりもリスクが高くなります。クライアントがパスワードを不正に使用したり、パスワードが攻撃者に誤って公開される可能性があります(たとえば、ログ・ファイルやクライアントによって保持されているその他のレコードを介して)。
アプリケーションは、パスワード資格証明を取得すると、ユーザー・リソースへの完全なアクセス権を持つスコープをリクエストできます。
パスワードの有効期限が切れます。
この権限は現在非推奨の状態です。

使用状況

「リソース所有者のパスワード資格証明の前提条件」を参照してください。