OAuthの構成

機密アプリケーションに関連付けられているアクセス・トークンの有効期間(秒)を定義します。

このチェック・ボックスは、「リソース所有者」、「認可コード」または「アサーション」権限付与タイプの使用時に取得するリフレッシュ・トークンを使用する場合に使用します。

アクセス・トークンとともに返され、機密アプリケーションに関連付けられているリフレッシュ・トークンの有効期間(秒)を定義します。

機密アプリケーションのアクセス・トークンが処理されるプライマリ受信者を入力します。

機密アプリケーションのアクセス・トークンを処理するセカンダリ受信者を入力し、「追加」を選択します。セカンダリ受信者は「セカンダリ・オーディエンス」列に表示され、「保護」列によってセカンダリ・オーディエンスが保護されているかどうかがわかります。

アプリケーションで他のアプリケーションのどの部分にアクセスするかを指定するには、それらのスコープを機密アプリケーションに追加します。

アプリケーションは、外部パートナまたは機密アプリケーションと安全に対話する必要があります。また、あるOracle Cloudサービスのアプリケーションは、別のOracle Cloudサービスのアプリケーションと安全に対話する必要があります。各アプリケーションには、他のアプリケーションが使用できるリソースを決定するアプリケーション・スコープがあります。

認可スコープが、クライアントの制御下にある保護リソースに、または認可サーバーに登録された保護リソースに制限されている場合に使用します。

クライアントは、独自の資格証明を提供してアクセス・トークンを取得します。このアクセス・トークンは、特定のリソース所有者ではなく、クライアントの独自のリソースに関連付けられているか、そうでなければクライアントがアクションを許可されているリソース所有者に関連付けられています

アサーションとして表される、認可サーバーでの直接的なユーザー承認ステップのない既存の信頼関係を使用する場合に使用します。

クライアントは、ユーザーJSON Webトークン(JWT)アサーションまたはサードパーティ・ユーザーJWTアサーションとクライアント資格証明を提供して、アクセス・トークンをリクエストします。JWTアサーションは、セキュリティ・ドメイン全体でのアイデンティティおよびセキュリティ情報の共有を容易にする情報のパッケージです。

SAML2アサーションとして表される、認可サーバーでの直接的なユーザー承認ステップのない既存の信頼関係を使用する場合に使用します。

クライアントは、ユーザーSAML2アサーションまたはサードパーティ・ユーザーSAML2アサーションとクライアント資格証明を提供して、アクセス・トークンをリクエストします。SAML2アサーションは、セキュリティ・ドメイン全体でのアイデンティティおよびセキュリティ情報の共有を容易にする情報のパッケージです。

この権限付与タイプは、クライアント・アプリケーションとリソース所有者間の仲介として認可サーバーを使用して、認可コードを取得する場合に選択します。

認可コードは、リソース所有者が認可サーバーに承諾を与えた後、ブラウザのリダイレクトを介してクライアントに返されます。その後、クライアントは認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークン)に交換します。リソース所有者の資格証明はクライアントに公開されません。

アプリケーションが認可サーバーによる認証に使用するクライアント資格証明の機密を保持できない場合は、このチェック・ボックスを選択しますたとえば、アプリケーションがJavaScriptなどのスクリプト言語を使用してWebブラウザに実装されている場合です。アクセス・トークンは、中間認可ではなく、リソース所有者の認可リクエストに応答してブラウザ・リダイレクトを介してクライアントに返されます。

「デバイス・コード」権限付与タイプは、クライアントがOAuth認可サーバーからリクエストを受信できない場合に選択します。たとえば、これはHTTPサーバーとして機能できません(ゲーム機、ストリーミング・メディア・プレーヤ、デジタル画像フレームなど)。

このフローで、クライアントは、ユーザー・コード、デバイス・コードおよび検証URLを取得します。次に、ユーザーは、個別のブラウザで検証URLにアクセスしてアクセス・リクエストを承認します。その後にのみ、クライアントはデバイス・コードを使用してアクセス・トークンを取得できます。

「TLSクライアント認証」権限付与タイプは、クライアント証明書を使用してクライアントで認証する場合に選択します。トークン・リクエストにX.509クライアント証明書が含まれ、リクエストされたクライアントが「TLSクライアント認証」権限付与タイプで構成されている場合、OAuthサービスは、リクエストのClient_IDを使用してクライアントを識別し、クライアント構成の証明書でクライアント証明書を検証します。クライアントは、2つの値が一致する場合にのみ正常に認証されます。

セキュリティを強化するには、「TLSクライアント認証」権限付与タイプを有効にする前に、OCSP検証を有効にして構成し、信頼できるパートナ証明書をインポートします。

このチェック ボックスは、[リダイレクトURL]、[ログアウトURL]、または [ログアウト後リダイレクトURL]フィールドにHTTP URLを使用する場合はオンにします。たとえば、内部的にリクエストを送信している場合、暗号化しない通信が必要な場合、またはOAuth 1.0との下位互換性が必要な場合は、HTTP URLを使用できます。

アプリケーションを開発またはテスト中でSSLを構成していない場合にも、このチェック・ボックスを選択します。このオプションは、本番デプロイメントには推奨されません。

認証後にユーザーがリダイレクトされるアプリケーションURLを入力します。

ノート: 絶対URLを指定します。相対URLはサポートされていません。

アプリケーションからのログアウト後にユーザーをリダイレクトするURLを入力します。

機密アプリケーションからのログアウト後にユーザーがリダイレクトされるURLを入力します。

クライアント・タイプを選択します。使用可能なクライアント・タイプは、「信頼できる」および「機密」です。クライアントが自己署名ユーザー・アサーションを生成できる場合は、「信頼できる」を選択します。その後で、クライアントが自己署名アサーションに署名するために使用する署名証明書をインポートするために、「証明書のインポート」を選択します。

コンテンツ暗号化アルゴリズムのいずれかを選択します。

有効にすると、この属性によって、アプリケーションに対して構成されているすべてのスコープの「同意が必要」属性が上書きされ、スコープに同意が不要になります。

クライアント・アプリケーションが認可されたリソースにアクセスできるようにするには、次のいずれかのオプションを選択します:

• すべて– ドメイン内の任意のリソース(すべて)にアクセスします。すべてのリソースへのアクセスを参照してください。

• 特定– クライアントとリソース(特定)の間に明示的な関連付けが存在するリソースのみにアクセスします。特定のスコープを持つリソースへのアクセスを参照してください。

ノート: 認可されたリソースを定義するオプションは、機密アプリケーションでのみ使用できます。信頼スコープは、モバイル・アプリケーションに対しては定義できません。

自分のアプリケーションが他のアプリケーションのAPIにアクセスする場合は、「トークン発行ポリシー」セクションで「リソースの追加」を選択します。次に、「スコープの追加」ウィンドウで、自分のアプリケーションが参照するアプリケーションを選択します。

ノート:スコープを削除するには、スコープの横にある「x」アイコンを選択します。ただし、保護されているスコープは削除できません。

「アプリケーション・ロールの追加」を選択します。「アプリケーション・ロールの追加」ウィンドウで、このアプリケーションに割り当てるアプリケーション・ロールを選択します。これにより、アプリケーションは、割り当てられた各アプリケーション・ロールでアクセス可能なREST APIにアクセスできるようになります。

たとえば、リストから「アイデンティティ・ドメイン管理者」を選択します。アプリケーションでは、アイデンティティ・ドメイン管理者が使用可能なすべてのREST APIタスクにアクセスできるようになります。

アプリケーション・ロールを削除するには、アプリケーション・ロールを選択し、「削除」を選択します。

ノート: 保護されたアプリケーション・ロールは削除できません。