52.2 Webクライアント用のOAuthサービスの認可の理解

最も一般的なOAuthシナリオでは、保護されたリソースにアクセスするクライアントには、ユーザーとは異なる資格証明のセットが発行されます。(この場合、ユーザーは自身の資格証明をクライアントに開示しません。)Oracle Access Management OAuthサービスは、クライアントと直接対話する中間認可サーバー、ユーザーの保護リソースをホストするサービス(リソース所有者)、およびリソースが存在するサーバー(リソース・サーバー)として機能します。

これは、リソース・サーバーで(すでに)正常に認証されているクライアントにアクセス・トークンを発行し、実際には、クライアントがサーバー上のプライベート・リソースまたはアクティビティにアクセスするのを認可します。1つの認可サーバー・インスタンスが、複数のリソース・サーバーによって受け入れられるアクセス・トークンを発行できます。

ノート:

OAuthは、リソース・サーバーと認可サーバー間の相互作用に特別な要件を課していません。

次の各項では、OAuthサービスが機能するWebベースのシナリオについて説明します。

このシナリオでは、OAuthサービス・エンドポイントの概念につて説明します。これらのエンドポイントの詳細は、「認可および認証エンドポイントの理解」を参照してください。このシナリオでは、次のものを含む、「OAuthサービス・コンポーネントの理解」に説明されている用語も使用します。

リソース所有者は、保護リソースへのアクセスをリクエストしているユーザーを指します。
クライアントは、リソース所有者が保護リソースへのアクセスをリクエストしているモバイル・アプリケーションまたはWebサービスです。
OAuthサービスは、認可サーバー、Oracle Access Managementを指します。
リソース・サーバーは、保護リソースが格納されるマシンです。これは、写真共有サイト、ブログ・プラットフォーム、プライベート・リソースおよびアクティビティへのオンライン・バンキング・サービス・コントロール・アクセスなど、制限されたリソースがあるWebサイトまたはWebサービスになります。リソース・サーバーは、Oracle Access Managementおよびクライアントと異なる場所にデプロイされます。リソース・サーバーは、アクセス・トークンを使用して保護されているリソースのリクエストを受け入れ、応答可能であることが必要です。リソース・サーバーでは、「アクセス制御の適用」に説明されているように、OAuthサービスでアクセス・トークンを検証する必要もあります。

52.2.1 3-legged認可の理解

3-legged認可では、リソース所有者が、OAuth保護リソース・サーバーに格納されているリソースにアクセスするために、OAuth対応クライアントにアクセス権を付与します。

Oracle Access Management OAuthサービスは、リソース所有者のアイデンティティを検証し、承認が必要な場合はWebブラウザで所有者に承認フォームを提示します。この認可スキームの3番目の脚は、ユーザーがクライアント・アクセス権を付与または拒否するステップです。次のテキストには、詳細が記載されており、図52-1にプロセスを示します。

ノート:

外部のLDAPディレクトリ・サーバーを使用する3-Legged認可を使用するには、Webゲート・プロキシが必要です。詳細は、「OAuthサービスを保護するためのWebゲートの構成」を参照してください。

リソース所有者(ユーザー)は、クライアントWebサービス(アプリケーション)が、別のサイト上のユーザーに属する保護リソースにアクセスすることを必要とするユーザー・エージェント(ブラウザなど)のアクションを起動します。
クライアントは、OAuthサービス認可エンドポイントを起動してリクエスト・トークンを取得することで、OAuthフローを開始します。クライアントは、その識別子、リクエストされたスコープ、およびアクセスが付与または拒否されると認可サーバーがユーザー・エージェントをダイレクトするリダイレクションURIを送信します。
OAuthサービスは、ユーザー・エージェントをリダイレクトして、リソース所有者のパスワード資格証明をリクエストします。
Access Managerはログイン・ページを表示し、リソース所有者にユーザー名とパスワードを求めます。OAuthサービスは、Access Managerによって提供されるすべての認証スキームをサポートします。
リソース所有者はユーザー名とパスワードを入力します。
Access Managerは、資格証明を検証してリクエスト・トークンを返し、ユーザー・エージェントをOAuthサービスにリダイレクトします。
OAuthサービスは、認可コードをクライアントに送信する前に、リソース・サーバーでユーザーの承認が必要であると判断します。
OAuthサービスは、ユーザー承認フォームを表示します。

Webベース・クライアントでは、承認フォームがWebゲートによって保護されている必要があります。詳細は、「OAuthサービスを保護するためのWebゲートの構成」を参照してください。
ユーザーはリクエストを承認します。
OAuthサービスは、リダイレクションURIを使用してクライアントに認可コードを返します。

ノート:
3-legged認可では、「認可コード」権限タイプが必要です。詳細は、「クライアント - Identity FederationおよびOAuthサービス」を参照してください。
クライアントは、トークン・エンドポイントにPOSTリクエストの認可コードを送信し(検証用の認可コードの取得に使用されるリダイレクションURIを含む)、OAuthアクセス・トークンをリクエストします。リクエストを行う際に、クライアントはOAuthサービスを使用して認証します。
クライアント・タイプがクライアント資格証明を必要とする場合、OAuthサービスはクライアント資格証明を認証し、認可コードを検証して、受信したリダイレクションURIが、認可コードを返すのに前に使用されたURIに一致していることを確認します。OAuthサービスは、リソース・サーバーの構成およびユーザーの承認の詳細に基づいて、リクエストされたスコープも検証します。
OAuthサービスは、アクセス・トークンをクライアントに返します。

リフレッシュ・トークンは、クライアントがリフレッシュ・トークン・リクエストを送信すると、アクセス・トークンとともに返される場合もあります。詳細は、「OAuthサービス・トークンについて」を参照してください。
クライアントはリソース・サーバーにアクセス・トークンを提供します。
リソース・サーバーは、OAuthサービスのトークン・エンドポイントにリクエストを送信することでアクセス・トークンを検証し、成功レスポンスまたは失敗レスポンスを待機します。
OAuthサービスは、検証してトークンの成功レスポンスまたは失敗レスポンスをリソース・サーバーに送り返します。
トークンが有効と判断されると、リソース・サーバーは、リクエストされたリソースをクライアントに戻します。

図52-1 OAuth 3-leggedフロー・ダイアグラム

「図52-1 OAuth 3-leggedフロー・ダイアグラム」の説明

52.2.2 2-legged認可の理解

2-legged認可では、OAuthクライアントはリソースへのアクセスが事前に承認されているため、ユーザー承認フォーム・ステップ(「3-Legged認可の理解」)は必要ありません。このシナリオでは、Access Managerがリクエスト・トークンをクライアントに返し、クライアントはそれをOAuthサービスに送信してアクセス・トークンをリクエストします。リクエスト・トークンは事前に認可されているため、承認フォームを表示することなく、OAuthのトークン・サービスはクライアントにアクセス・トークンを返します。このアレンジは、サービス対サービスのモデルに適合し、特に、リクエスト・サービス(クライアント)およびリソース・サーバーが密接なパートナシップを持ち、リソース所有者の承認が想定されるか、必要とされない場合に適しています。

ノート:

2-legged認可では、「クライアント資格証明」権限タイプまたは「リソース所有者の資格証明」権限タイプが必要です。詳細は、「クライアントの構成」を参照してください。