52.5 OAuthサービス・トークンについて

OAuthサービスでは、クライアント・トークン、ユーザー・トークンおよびアクセス・トークンを生成します。

クライアント・トークンは、機密クライアントまたはモバイル・クライアントにスコープなしの「クライアント資格証明」権限タイプを使用する場合に、OAuthサービスによって生成されます。ユーザー・トークンは、スコープなしの「ユーザー資格証明」権限タイプを使用する場合に、OAuthサービスによって生成されます。アクセス・トークンは、スコープ・パラメータを使用して、サポートされている権限タイプで生成されます。権限タイプの詳細は、「クライアント - Identity FederationおよびOAuthサービス」を参照してください。

ノート:

ユーザーおよびクライアントでは、3つのトークンのいずれかの検証および生成用に、JWTトークンまたはアサーションの形式の資格証明を提供できます。OAuthサービスによって生成されるクライアント・トークンまたはユーザー・トークンをクライアント・アサーションまたはユーザー・アサーションとしてそれぞれ使用できますが、これは一般的ではありません。

リフレッシュ・トークンもOAuthサービスによって生成されます。これは、オフライン・スコープがアクセス・トークン・リクエストで表示されると発行され、通常はアクセス・トークンよりも有効期限が後になります。リフレッシュ・トークンは、アクセス・トークンを取得するのに使用できます。次の各項では、さらに詳細を説明します。

52.5.1 OAuthサービス・アクセス・トークン

保護リソースへのアクセスのリクエストをユーザーが承認する必要があるとOAuthサービスが判断すると、承認フォームが表示されます。ユーザー承認後、OAuthサービスは認可コードをクライアント・サービス・プロバイダに返します。クライアントは、次に認可コードをトークン・エンドポイントに送信して、OAuthサービス・アクセス・トークンをリクエストします。(リクエストを行う際に、クライアントはOAuthサービスを使用して認証します。)受信すると、アクセス・トークンで保護リソースにアクセスできます。トークン・エンドポイントの詳細は、「認可および認証エンドポイントの理解」を参照してください。

Oracle Access Managementは、カスタム属性をアクセス・トークンに埋め込むことができます。カスタム属性は、サービス・プロファイルまたはカスタム・リソース・サーバーの一部として構成されます。これらは、静的または動的として定義されます。

静的属性: 属性の定義時に値が固定される属性名と値のペア。例: name1=value1
動的属性: ユーザープロファイル固有の属性。「サービス・プロファイル構成」ページの「ユーザー・ストア」設定を構成することもできます。この設定は、ユーザー・プロファイル属性のソースを定義します。ユーザー・プロファイル・サービス(および/または基礎となるIDSインタフェース)を使用して、属性の名前と値を取得できます。動的属性はユーザーに関連するため、ユーザー承認ページ(構成されている場合)には、構成された属性がクライアントおよびリソースと共有されていることが示されます。

詳細は、「サービス・プロファイルの構成」および「サービス・プロファイルの構成」を参照してください。カスタム属性の構成時には、次のガイドラインに従ってください。

静的属性および動的属性に同じ名前を使用しないでください。
サービス・プロファイル構成およびスコープ構成にカスタム属性を追加する際には同じ名前を使用しないでください。両方の場所に同じ属性名を定義する場合は、スコープベースの属性値が優先されます。

カスタム属性はアクセス・トークンの要求として表示されます。JWTベースのアクセス・トークンにはOAuthサービス固有の要求とともに標準のJWT要求が含まれます。次に例を示します。

標準

"exp":1357596398000,
"iat":1357589198000,
"aud":"oam_server1",
"iss":"OAuthServiceProfile",
"prn":null,
"jti":"340c8324-e49f-43cb-ba95-837eb419e068",

OAuthサービス固有

"oracle.oauth.user_origin_id":"john101",
"oracle.oauth.user_origin_id_type":"LDAP_UID",
"oracle:idm:claims:client:macaddress":"1C:AB:A7:A5:F0:DC",
"oracle.oauth.scope":"brokerage",
"oracle.oauth.client_origin_id":"oauthssoapp1id",
"oracle.oauth.grant_type":"oracle-idm:/oauth/grant-type/resource-access-token/jwt"

これらの要求は、OAuthサービスで生成されたアクセス・トークンの一部として使用できます。カスタム属性はJWTベースのアクセス・トークンで要求として表示されるため、次の名前付け制限が適用されます。

JWT標準要求名は使用しないでください。
Oracle接頭辞が付く名前は使用しないでください(前述のとおり)。

52.5.2 OAuthサービス・リフレッシュ・トークン

OAuthサービスは、クライアントがリフレッシュ・トークンを使用して同じまたはより狭いスコープの追加のアクセス・トークンを取得できるように構成できます。

アクセス・トークンが無効になると、リフレッシュ・トークンが使用されます。リフレッシュ・トークンの目的は、セキュリティを向上することです。アクセス・トークンは短期間のため、盗難された場合でも限定された期間しか使用できません。リフレッシュ・トークンは長期間ですが、サーバーに送信される頻度が低いため、盗難される可能性が減ります。

どのスコープでもリフレッシュ・トークンをリクエストして使用できますが、リフレッシュ・トークンは通常、ユーザーがオフラインのときに使用されます。管理者は、リソース・サーバーを構成するときに、1つのスコープをオフライン・スコープとして指定できます。オフライン・スコープとして指定されたスコープがアクセス・トークン・リクエストに含まれている場合、サーバーはそのアクセス・トークンとともにリフレッシュ・トークンを含めます。オフライン・スコープ・フィールドが構成されていない場合、サーバーはリフレッシュ・トークンを発行しません。詳細は、「「カスタム・リソース・サーバー構成」ページ」を参照してください。

リフレッシュ・トークンを使用するようにクライアントを構成する必要があります。リフレッシュ・トークン設定の詳細は、「「サービス・プロファイル構成」ページ」および「Webクライアント構成ページ」を参照してください。

52.5.3 モバイルOAuthサービス・クライアント・トークン

モバイル・アプリケーションは、OAuthサービスを使用する前にOracle Access Managementに登録する必要があり、各登録はデバイス上のアプリケーションに固有です。

アプリケーションの登録後、モバイル・アプリケーションにはクライアント・トークンが含まれます。このトークンは、アクセス・トークン・リクエストを行うためのセキュリティ資格証明として使用されます。詳細は、「モバイルOAuthサービスのサーバー側シングル・サインオンの理解」を参照してください。