OAuth 2.0の付与について

次のセクションでは、「Oracle Utilitiesアダプタ」認証機能について詳しく説明します。

この認証スキームにより、外部クライアントは、Oracle UtilitiesアプリケーションAPIを呼び出すために送信されたリクエストの一部としても送信されるトークンを取得できます。

OAuthフロー内でアプリケーションの最も重要なステップは、アプリケーションがアクセス・トークン(オプションでリフレッシュ・トークンとともに)を受け取ることです。権限付与タイプは、トークンを取得するのに使用されるメカニズムです。 OAuthでは、様々な認可メカニズムを表す複数のアクセス権限付与タイプが定義されています。

アプリケーションは、Oracle Identity Cloud Serviceアプリケーションで指定された付与タイプのタイプに応じて、様々な方法で保護されたエンドポイントにアクセスするためのアクセス・トークンをリクエストできます。権限付与とは、保護されているリソースにアクセスするためのリソース所有者の認可を表す資格証明です。

次の各項では、様々な権限付与タイプとその長所/短所、および特定の権限付与タイプの構成方法について説明します。

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

権限付与タイプ	権限付与タイプについて	ユースケースとリスク
リソース所有者のパスワード資格証明(ROPC)	アクセス・トークンを取得するための認可付与として、OAuthクライアントがリソース所有者のパスワード資格証明(つまり、ユーザー名とパスワード)を直接使用できます。リソース所有者のパスワード資格証明権限付与タイプは、リソース所有者がOAuthクライアントと信頼関係を持つ場合に適しています。リソース所有者のパスワード資格証明の付与を使用する場合、ユーザーが資格証明(ユーザー名とパスワード)を直接アプリケーションに指定します。次に、アプリケーションが資格証明を使用して、OAuthトークン・サービスからアクセス・トークンを取得します。リソース所有者のパスワード資格証明の付与は、クライアント・アプリケーションがそのクライアント識別子およびシークレットとともにユーザー名とパスワードを送信して、アクセス・トークンと交換する付与ワークフローです。ユーザーは、webインタフェースでログインして認可リクエストを承認するかわりに、クライアント・アプリケーション・ユーザー・インタフェースでユーザー名とパスワードを直接入力できます。このワークフローには、他のOAuthワークフローとは異なるセキュリティ・プロパティがあります。主な違いは、アプリケーションからユーザーのパスワードにアクセスできることです。このことは、アプリケーションに対するユーザーの強い信頼を必要とします。リソース所有者のパスワード資格証明の付与には、次の特性があります: クライアントには、ユーザー資格証明に関する知識が必要です。ブラウザベースのエンド・ユーザー操作ではありません。リフレッシュ・トークンが許可されます。アクセス・トークンは、エンド・ユーザーのコンテキスト内にあります。このOAuthフローは次のとおりです。ユーザーは、保護されたリソースへのアクセスをリクエストするクライアント・アプリケーション内のリンクをクリックします。クライアント・アプリケーションは、リソース所有者のユーザー名とパスワードをリクエストします。ユーザーは自分のユーザー名とパスワードでログインします。クライアント・アプリケーションは、これらの資格証明をOracle Identity Cloud Service認可サーバーからアクセス・トークン(通常はリフレッシュ・トークン)と交換します。 Oracle Identity Cloud Service認可サーバーは、クライアント・アプリケーションにアクセス・トークンを返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	この権限付与は、ユーザーの介入なしでプログラムによって統合を起動するアプリケーションで使用できます。この権限は、ユーザー資格証明を安全に処理する信頼できるファースト・パーティのクライアントでのみ使用します。この権限付与タイプは、クライアント・アプリケーションでOAuthアクセス・トークンを取得して、プログラム的な方法で統合を起動するリクエストを送信するために使用できますが、Oracle Integrationは、次のリスクのためにリソース所有者のパスワード資格証明の付与を推奨しません: リスクこの権限付与タイプは、このプロトコルが回避するために検索するパスワード・アンチ・パターンを保持するため、他の権限付与タイプよりもリスクが高くなります。クライアントがパスワードを不正に使用したり、パスワードが攻撃者に誤って公開される可能性があります(たとえば、ログ・ファイルやクライアントによって保持されているその他のレコードを介して)。アプリケーションは、パスワード資格証明を取得すると、ユーザー・リソースへの完全なアクセス権を持つスコープをリクエストできます。パスワードの有効期限が切れます。使用状況「リソース所有者のパスワード資格証明の前提条件」を参照してください。
クライアント資格証明	クライアント資格証明の付与は、OAuthクライアント自体がデータを所有し、リソース所有者からの委任アクセスを必要としない場合に使用されます。クライアント資格証明の付与には固有の付与フローがあり、これには、リソース所有者(つまりユーザー)が関与しません。この権限を使用する場合、クライアント・アプリケーションは自身の資格証明(識別子とシークレット)またはトークン・エンドポイントからのアサーションのみを使用してアクセス・トークンをリクエストし、クライアント・アプリケーション自体のかわりにアクセス・トークンを使用します。トークン・エンドポイントはリフレッシュ・トークンを発行しません。これは、リフレッシュ・トークンはクライアント資格証明の付与ではサポートされないためです。アクセス・トークンが期限切れになると、クライアント・アプリケーションは新しいアクセス・トークンをリクエストする必要があります。クライアント資格証明には次の特性があります: 機密のOAuthクライアントで使用されます。 OAuthクライアント・アプリケーションは、リソース所有者のかわりにではなく、サービス・プロバイダと直接通信します。フローはリダイレクションベースではありません。アクセス・トークンはエンド・ユーザーのコンテキスト外にあります。このOAuthフローは次のとおりです。ユーザーがwebサーバー・クライアント・アプリケーションのリンクをクリックして、保護されたリソースへのアクセスをリクエストします。クライアント・アプリケーションは、資格証明をOracle Identity Cloud Service認可サーバーからアクセス・トークンと交換します。 Oracle Identity Cloud Service認可サーバーは、クライアント資格証明を検証し、アクセス・トークンをクライアント・アプリケーションに返します。クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。	クライアント資格証明の付与を使用するOAuthクライアントには、許可サーバー上の資格証明が必要です。つまり、クライアントは機密クライアントである必要があります。クライアント資格証明の付与では、クライアントにリソース所有者の許可が必要ないため、統合サーバーは所有者を認識しません。この付与フローは、サービス・プロバイダが特定のリソース所有者に適用されるメソッドではなく、クライアント・アプリケーションで使用するAPIメソッドを一般に提供する場合に最適です。使用状況「OAuthクライアント資格証明の前提条件」を参照してください

権限付与タイプ

権限付与タイプについて

ユースケースとリスク

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

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

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

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

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

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

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

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

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

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

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

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

リスク

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

使用状況

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

クライアント資格証明

クライアント資格証明の付与は、OAuthクライアント自体がデータを所有し、リソース所有者からの委任アクセスを必要としない場合に使用されます。クライアント資格証明の付与には固有の付与フローがあり、これには、リソース所有者(つまりユーザー)が関与しません。この権限を使用する場合、クライアント・アプリケーションは自身の資格証明(識別子とシークレット)またはトークン・エンドポイントからのアサーションのみを使用してアクセス・トークンをリクエストし、クライアント・アプリケーション自体のかわりにアクセス・トークンを使用します。トークン・エンドポイントはリフレッシュ・トークンを発行しません。これは、リフレッシュ・トークンはクライアント資格証明の付与ではサポートされないためです。アクセス・トークンが期限切れになると、クライアント・アプリケーションは新しいアクセス・トークンをリクエストする必要があります。

クライアント資格証明には次の特性があります:

機密のOAuthクライアントで使用されます。
OAuthクライアント・アプリケーションは、リソース所有者のかわりにではなく、サービス・プロバイダと直接通信します。
フローはリダイレクションベースではありません。
アクセス・トークンはエンド・ユーザーのコンテキスト外にあります。

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

ユーザーがwebサーバー・クライアント・アプリケーションのリンクをクリックして、保護されたリソースへのアクセスをリクエストします。
クライアント・アプリケーションは、資格証明をOracle Identity Cloud Service認可サーバーからアクセス・トークンと交換します。
Oracle Identity Cloud Service認可サーバーは、クライアント資格証明を検証し、アクセス・トークンをクライアント・アプリケーションに返します。
クライアント・アプリケーションは、APIコールでアクセス・トークンを使用して統合を起動します。

クライアント資格証明の付与を使用するOAuthクライアントには、許可サーバー上の資格証明が必要です。つまり、クライアントは機密クライアントである必要があります。

クライアント資格証明の付与では、クライアントにリソース所有者の許可が必要ないため、統合サーバーは所有者を認識しません。

この付与フローは、サービス・プロバイダが特定のリソース所有者に適用されるメソッドではなく、クライアント・アプリケーションで使用するAPIメソッドを一般に提供する場合に最適です。

使用状況

「OAuthクライアント資格証明の前提条件」を参照してください