37 OAuthサービスの理解

OAuthでは、アクセス・トークン用のアイデンティティ資格証明を交換する方法を提供します。このトークンは、アイデンティティ資格証明をコンシューマ・サイトに漏らす必要なく、1つのサービス・プロバイダ・サイトのユーザーのアカウントのプライベート・リソースのアクセス権を2つ目のコンシューマ・サイトに付与するのに使用できます。

Oracle Access Managementでは、OAuth Core 2.0仕様を実装して、OAuthサービスを提供します。この章では、Oracle Access Management OAuthサービスの用途と機能について説明します。

この節では、以下のトピックについて説明します。

• Oracle Access Management OAuthサービスについて

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

• OAuthサービス・コンポーネントの理解

• OAuthトークンについて

37.1 Oracle Access Management OAuthサービスについて

OAuthは、クライアント(Webサービスなど)とWeb上のリソース所有者(またはサービス・プロバイダ)間の認証およびアクセス制御を提供するオープン・スタンダードな認可プロトコルです。

Oracle Access Management OAuthサービスは、この標準に基づいており、次のように設計されています。

• エンタープライズ・レベルのエクストラネットのユースケースに対処する。

• APIへのセキュアなアクセスを提供する。

• 組込みのOracle Access Management機能(認証スキーム、厳密認証、不正検出、セッション管理、フェデレーテッド認証など)を活用する。

• 高いレベルのセキュリティで機密性クライアントを保護する。

Oracle Access Management OAuthサービスは、Webクライアントで使用できます。Webクライアント用のOAuthサービスは、標準のOAuth 2.0ユースケースを実現します。この場合、クライアントは、クライアントID/クライアント・パスワード(秘密)を利用して自身を保護します。例は、http://tools.ietf.org/html/rfc6749#page-4を参照してください。

関連項目

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

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

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

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

ノート:

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

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

• 3-legged認可の理解

• 2-legged認可の理解

このシナリオでは、OAuthサービス・エンドポイントの概念につて説明します。各シナリオでは、次の用語も使用します。

• リソース所有者は、保護されているリソースへのアクセス権を付与することが可能なエンティティです。リソース所有者が個人である場合、エンド・ユーザーと呼ばれます。

• クライアントは、リソース所有者のかわりにその認可を使用して、保護されているリソースのリクエストを作成するアプリケーションです。

• OAuthサービスは、認可サーバー、Oracle Access Managementを指します。

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

37.2.1 3-legged認可の理解

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

Oracle Access Management OAuthサービスは、リソース所有者のアイデンティティを検証し、承認が必要な場合はWebブラウザで所有者に承認フォームを提示します。

この認可スキームの3番目の脚は、ユーザーがクライアント・アクセス権を付与または拒否するステップです。

承認管理が有効な場合、後続のOAuth 3-leggedフローは承認処理をスキップします。詳細は、「承認管理の有効化」を参照してください。

次のテキストには、詳細が記載されており、図37-1にプロセスを示します。

ノート:

外部のLDAPディレクトリ・サーバーを使用する3-Legged認可を使用するには、Webゲート・プロキシが必要です。

1. リソース所有者(ユーザー)は、クライアントWebサービス(アプリケーション)が、別のサイト上のユーザーに属する保護リソースにアクセスすることを必要とするユーザー・エージェント(ブラウザなど)のアクションを起動します。

2. クライアントは、OAuthサービス認可エンドポイントを起動してリクエスト・トークンを取得することで、OAuthフローを開始します。クライアントは、その識別子、リクエストされたスコープ、およびアクセスが付与または拒否されると認可サーバーがユーザー・エージェントをダイレクトするリダイレクションURIを送信します。

3. OAuthサービスは、ユーザー・エージェントをリダイレクトして、リソース所有者のパスワード資格証明をリクエストします。

4. Access Managerはログイン・ページを表示し、リソース所有者にユーザー名とパスワードを求めます。OAuthサービスは、Access Managerによって提供されるすべての認証スキームをサポートします。

5. リソース所有者はユーザー名とパスワードを入力します。

6. Access Managerは、資格証明を検証してリクエスト・トークンを返し、ユーザー・エージェントをOAuthサービスにリダイレクトします。

7. OAuthサービスは、認可コードをクライアントに送信する前に、リソース・サーバーでユーザーの承認が必要であると判断します。

8. OAuthサービスは、ユーザー承認フォームを表示します。

   ノート:

   承認管理が有効な場合、承認フォームは、最初の3-legged認可フロー中にのみ表示されます。ユーザーがアクセス権を付与すると、承認はデータベースに保持され、OAMは後続の3-legged OAuthフローでの承認をスキップします。

   Webベース・クライアントには、Webゲートで保護された承認フォームが必要です。

9. ユーザーはリクエストを承認します。

10. OAuthサービスは、リダイレクションURIを使用してクライアントに認可コードを返します。

    ノート:

    3-legged認可では、「認可コード」権限タイプが必要です。詳細は、「クライアント」を参照してください。

11. クライアントは、トークン・エンドポイントにPOSTリクエストの認可コードを送信し(検証用の認可コードの取得に使用されるリダイレクションURIを含む)、OAuthアクセス・トークンをリクエストします。リクエストを行う際に、クライアントはOAuthサービスを使用して認証します。

12. クライアント・タイプがクライアント資格証明を必要とする場合、OAuthサービスはクライアント資格証明を認証し、認可コードを検証して、受信したリダイレクションURIが、認可コードを返すのに前に使用されたURIに一致していることを確認します。OAuthサービスは、リソース・サーバーの構成およびユーザーの承認の詳細に基づいて、リクエストされたスコープも検証します。

13. OAuthサービスは、アクセス・トークンをクライアントに返します。

    リフレッシュ・トークンは、クライアントがリフレッシュ・トークン・リクエストを送信すると、アクセス・トークンとともに返される場合もあります。詳細は、「OAuthトークンについて」を参照してください。

14. クライアントはリソース・サーバーにアクセス・トークンを提供します。

15. リソース・サーバーは、OAuthサービスのトークン・エンドポイントにリクエストを送信することでアクセス・トークンを検証し、成功レスポンスまたは失敗レスポンスを待機します。

16. OAuthサービスは、検証してトークンの成功レスポンスまたは失敗レスポンスをリソース・サーバーに送り返します。

17. トークンが有効と判断されると、リソース・サーバーは、リクエストされたリソースをクライアントに戻します。

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

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

37.2.2 2-legged認可の理解

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

ノート:

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

37.3 OAuthサービス・コンポーネントの理解

次の各項では、アイデンティティ・ドメインの構成オプションの詳細について説明します。これらのコンポーネントの構成の詳細は、「12cでのOAuthサービスの構成」を参照してください。

• アイデンティティ・ドメイン

• クライアント

37.3.1 アイデンティティ・ドメイン

アイデンティティ・ドメインは、標準のOAuthサービスの提供に必要なすべてのアーティファクトを含むエンティティです。

各アイデンティティ・ドメインは、独立したエンティティです。アイデンティティ・ドメインの主要なユースケースの1つは、マルチ・テナントのデプロイメントです。各アイデンティティ・ドメインは、1つのテナントに対応します。独立性が必要な場合は、組織内の様々な部門に適用できます。これは、各アイデンティティ・ドメインが個別のテナントまたはエンティティに対応できるクラウド・デプロイメントにも便利です。次のアーティファクトは、OAuthサービス・アイデンティティ・ドメイン内で構成されるコンポーネントの一部にすぎません。

• 1つ以上のクライアント

• 1つ以上のリソース・サーバー

アイデンティティ・ドメインの構成の詳細は、「アイデンティティ・ドメインの作成」を参照してください。

37.3.2 クライアント

クライアントは、OAuthサービスを起動することで、OAuthプロトコルを開始します。

プロトコルを開始する前に、クライアント・プロファイルを作成する必要があります。クライアント・プロファイルには最低限、アプリケーション名、クライアントID、およびアクセスが付与または拒否された場合に、OAuthサービスがユーザー・エージェントをリダイレクトするURIが1つ以上含まれます。クライアントは、パブリックまたは機密のいずれかです。

• Webクライアントは、機密クライアントの一種で、クライアントIDおよび秘密が割り当てられます。これらのクライアントは、クライアントIDおよび秘密を認可ヘッダーの一部として送信することで、OAuthサービス・サーバーと対話できます。それらに発行される秘密をどのようにして安全に格納するかを決定するのは、各クライアントです。

• パブリック・クライアントには、クライアントIDが割り当てられますが、秘密は割り当てられません。通常、これらのプロファイルは、JavaScriptなどのブラウザ・ベースのアプリケーションに関係しますが、モバイル・ベースのアプリケーションにもなります。

クライアントIDおよび秘密は、次の箇条書きに説明されています。

• クライアントIDは、登録情報を表す一意の文字列で、クライアントごとに必要です。一意のクライアントIDを作成したり、OAuthサービスで生成できます。OAuthサービスでは、定義済のクライアントIDと、認可リクエストの一部としてクライアントがHTTPSまたはHTTP経由で送信する値を比較します。値が一致しない場合、リクエストは否認されます。クライアントIDは、認可ヘッダーとして送信されるとBase64でエンコードされます。

• クライアントの秘密は、クライアント・パスワードです。一意のクライアント秘密を作成したり、OAuthサービスで生成できます。Webクライアントには、クライアントIDおよびクライアント秘密を含める必要があります。これに対し、パブリック・クライアントには、クライアント秘密が含まれず、クライアントIDのみが割り当てられます。

アクセス・トークンをリクエストするために、クライアントはリソース所有者から認可を取得します。認可は、クライアントがアクセス・トークンのリクエストに使用する認可権限の形で表されます。OAuth 2.0仕様には、様々なセキュリティ・ユースケースに対応した認可権限タイプが用意されています。OAuthサービスでは、これらの権限タイプの一部を実装しています。Webクライアントとパブリック・クライアントでは、それらに適した様々なOAuthサービス権限タイプにアクセスできます。OAuthサービスでは、次の権限タイプがサポートされています。

ノート:

(OAuth仕様の権限タイプの概要は、http://tools.ietf.org/html/rfc6749#section-1.3を参照してください。)

• 認可コード - Oracle Access Management使用時のリソース所有者のログ。トークン・エンドポイントはクライアント資格証明とともに認可コードをアクセス・トークンと交換します。3-leggedフローでは、「認可コード」権限タイプが必要です。

• リソース所有者の資格証明 - リソース所有者はクライアントにユーザー名とパスワードを提供します。クライアントがパスワードを乱用したり、パスワードが誤って攻撃者に開示される可能性があるため、これは信頼性の高いクライアント・アプリケーションにのみ適しています。OAuth 2.0仕様ごとに、認可サーバーおよびクライアントは、この権限タイプの使用を最小限に抑え、可能な場合は常に他の権限タイプを利用する必要があります。「リソース所有者の資格証明」権限タイプは、2-legged認可シナリオに必要です。

• クライアント資格証明 – クライアントはそのクライアント資格証明のみ(または他のサポートされている認証手段)を使用してアクセス・トークンをリクエストします。これは、クライアントがその制御下、または認可サーバーで前に調整されたときの別のリソース所有者の制御下にある保護されているリソースへのアクセスをリクエストしている場合に適しています。「クライアント資格証明」権限タイプは、2-legged認可シナリオに必要です。

• リフレッシュ・トークン - このオプションを選択すると、トークン・レスポンスでアクセス・トークンとともにリフレッシュ・トークンを返します。詳細は、「OAuthトークンについて」を参照してください。

• JWTベアラー - OAuthサービス・アクセス・トークンのリクエストにJWTアサーションを使用できます。

クライアントごとに「許可されているスコープ」をクライアントに構成することもできます。OAuthサービスにより、ユーザー承認を必要とせずにスコープを構成できます。クライアントの構成の詳細は、「クライアントの作成」を参照してください。

37.4 OAuthトークンについて

OAuthでは、アクセス・トークンとリフレッシュ・トークンという2つのタイプのトークンが生成されます。

アクセス・トークンは、リソースに直接アクセスするために必要な情報を提供します。つまり、リソースを管理しているサーバーにクライアントがアクセス・トークンを渡すと、そのサーバーは、トークンに格納されている情報を使用して、そのクライアントに権限があるかどうかを判断できます。アクセス・トークンには、通常、有効期限があり、存続期間は短く設定されています。

リフレッシュ・トークンは、新しいアクセス・トークンを取得するために必要な情報を提供します。つまり、特定のリソースにアクセスするためにアクセス・トークンが必要な場合、クライアントは、常にリフレッシュ・トークンを使用して、認証サーバーから発行された新しいアクセス・トークンを取得できます。一般的なユースケースには、古いアクセス・トークンの期限が切れた後に新しいものを取得する場合や、新しいリソースに最初にアクセスする場合などがあります。リフレッシュ・トークンにも有効期限がありますが、存続期間は比較的長く設定されています。次の各項では、さらに詳細を説明します。

• OAuthアクセス・トークン

• OAuthリフレッシュ・トークン

• OAuthトークンの取消し

37.4.1 OAuthアクセス・トークン

ユーザーが保護されているリソースにアクセスする前に、クライアント・サービス・プロバイダは、OAuthサービスを使用して認証し、OAuthアクセス・トークンのトークン・エンドポイントをリクエストします。

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

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

• 静的属性 - 属性の定義時に値が固定される属性名と値のペア。たとえば、name1=value1

• 動的属性- ユーザープロファイル固有の属性。たとえば:

   $session.id, 
  {"attrName":"sessionId",
  "attrValue":"$session.id",
  "attrType":"DYNAMIC"
  }

詳細は、「リソースの作成」および「クライアントの作成」を参照してください。カスタム属性の構成時には、次のガイドラインに従ってください。

• 静的属性および動的属性に同じ名前を使用しないでください。

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

カスタム属性はアクセス・トークンの要求として表示されます。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接頭辞が付く名前は使用しないでください(前述のとおり)。

37.4.2 OAuthリフレッシュ・トークン

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

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

リフレッシュ・トークンは、リソース所有者の資格証明および認可コード・フローでのみ生成されます。これは、IdentityDomainのtokenSettings構成でも制御されます。

37.4.3 OAuthトークンの取消し

OAMは、アクセス・トークンおよびリフレッシュ・トークンの取消しをサポートすることで、OAuthフローのセキュリティを強化します。

詳細は、「OAuthトークンの取消し」を参照してください。