クライアントIDメタデータ・ドキュメント

次の用語では、CIMDフローで使用されるアイデンティティ、OAuthおよびセキュリティの概念について説明します。

• IAM: Identity and Access Management。

• IDCS: Oracle Identity Cloud Service。

• MCP: AIアプリケーションが外部ツール、データ・ソース、サービスに接続する方法を標準化するオープン・プロトコル。このドキュメントでは、Model Context Protocol (MCP)クライアントがOAuthを使用して、保護されたMCPリソースにアクセスします。

• IDCS/IAMドメイン: OAuthおよびアイデンティティ・サービスを提供するOracle Identity Cloud ServiceまたはOCI IAMアイデンティティ・ドメイン。

• CIMD: クライアントIDメタデータ・ドキュメント。クライアントがメタデータ・ドキュメントのHTTPS URLをOAuth client_idとして使用する標準整列モデル。

• メタデータ・ドキュメント: 必要なクライアント・メタデータ・フィールド(client_id、client_name、redirect_uris、grant_types、response_typesおよびtoken_endpoint_auth_method)を宣言するパブリッシャがホストするJSONドキュメント。

• CIMDクライアント: 認可、同意、トークン、監査および認可処理のために検証されたCIMDドキュメントから作成された、存続期間の短いIAMドメイン・スコープのクライアント・アイデンティティです。

• 信頼できるメタデータ・オリジン: IDCS/IAMがCIMDコンテンツをフェッチする前に、IAMドメインによって明示的に信頼されているメタデータURLオリジン。

• PKCE: コード交換用のプルーフ・キー。パブリックCIMD承認コード要求に必要です。

• JWKS: JSON Webキー・セット。CIMDクライアントがprivate_key_jwtを使用している場合に公開キーを公開するために使用されます。

• SSRF: サーバー側のリクエスト・フォージェリ。CIMDメタデータおよびキーの取得では、SSRF対応URL、DNS、リダイレクト、タイムアウト、プロキシおよびペイロード・サイズの制御を適用する必要があります。

ドメインでCIMDクライアントを処理するには、アイデンティティ・ドメインに対してCIMDサポートを有効にする必要があります。クライアントがIAM認可サーバーを介してサインインする前に、各CIMDクライアント・メタデータURIをアイデンティティ・ドメイン・ドメイン許可リストを持つIAMに追加します。

アイデンティティ・ドメインでCIMDサポートが有効な場合、認可サーバー・メタデータは、client_id_metadata_document_supportedを値trueに含めてCIMDサポートを通知します。アイデンティティ・ドメインはこのプロパティを通知するのは、CIMDサポートが有効な場合のみです。

{
  "issuer": "https://identity.oraclecloud.com/",
  "authorization_endpoint": "https://<idcs-stripe-url>/oauth2/v1/authorize",
  "token_endpoint": "https://<idcs-stripe-url>/oauth2/v1/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "private_key_jwt",
    "client_secret_post",
    "none"
  ],
  "token_endpoint_auth_signing_alg_values_supported": ["RS256"],
  "jwks_uri": "https://<idcs-stripe-url>/admin/v1/SigningCert/jwk",
  "scopes_supported": [
    "openid",
    "profile",
    "offline_access",
    "email",
    "address",
    "phone",
    "groups",
    "get_groups",
    "approles",
    "get_approles"
  ],
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code token",
    "code id_token",
    "token id_token",
    "code token id_token"
  ],
  "ui_locales_supported": ["en"],
  "revocation_endpoint": "https://<idcs-stripe-url>/oauth2/v1/revoke",
  "introspection_endpoint": "https://<idcs-stripe-url>/oauth2/v1/introspect",
  "code_challenge_methods_supported": ["S256"],
  "secure_authorization_endpoint": "https://<idcs-stripe-regional-url>/oauth2/v1/authorize",
  "secure_token_endpoint": "https://<idcs-stripe-regional-url>/oauth2/v1/token",
  "secure_userinfo_endpoint": "https://<idcs-stripe-regional-url>/oauth2/v1/userinfo",
  "secure_revocation_endpoint": "https://<idcs-stripe-regional-url>/oauth2/v1/revoke",
  "secure_introspection_endpoint": "https://<idcs-stripe-regional-url>/oauth2/v1/introspect",
  "secure_jwks_uri": "https://<idcs-stripe-regional-url>/admin/v1/SigningCert/jwk",
  "grant_types_supported": [
    "client_credentials",
    "password",
    "refresh_token",
    "authorization_code",
    "urn:ietf:params:oauth:grant-type:jwt-bearer",
    "tls_cert_auth"
  ],
  "userinfo_endpoint": "https://<idcs-stripe-url>/oauth2/v1/userinfo",
  "client_id_metadata_document_supported": true
}

この認可サーバー・メタデータの権限付与タイプ、レスポンス・タイプおよびトークン・エンドポイント認証方法の値は、アイデンティティ・ドメインの一般的なOAuth機能を記述します。CIMD固有の制限は上書きされません。CIMDクライアントの場合、「サポートされているOAuthフロー」および「クライアント・メタデータ要件」に記載されているOAuthフローおよび認証方法のみを使用します。

アイデンティティ・ドメインがCIMDに対して信頼できるHTTPSクライアント・メタデータURIを使用して、アイデンティティ・ドメイン・ドメイン許可リストを使用してIAMを構成します。例に示すように、domainUri値には完全なHTTPSメタデータ・ドキュメントURLを使用します。

CIMDメタデータ・ドキュメントを取得する前に、アイデンティティ・ドメインは、CIMD client_idがドメイン構成によって信頼されていることを確認します。クライアント識別子が信頼されていない場合、アイデンティティ・ドメインはメタデータ・ドキュメントを取得する前にCIMDリクエストを拒否します。

PATCH https://<idcs-stripe-url>/admin/v1/Settings/Settings
{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "add",
      "path": "allowedCimdDomains",
      "value": [
        {
          "domainUri": "https://client.example.com/oauth/client-metadata.json"
        },
        {
          "domainUri": "https://developer.example.net/oauth/client-metadata.json"
        }
      ]
    }
  ]
}

• CIMDサポートの概要
• CIMDクライアントを許可するアプリケーションの構成
• CIMD認証とトークンの例

CIMDクライアントを保護されたリソース・アプリケーション許可リストに追加する前に、アイデンティティ・ドメイン・ドメイン許可リストを含むIAMにクライアント・メタデータの場所を追加します。

CIMDクライアントは、完全なHTTPS CIMDクライアント識別子がリソースに対して認可されている場合にのみ、顧客定義のOAuthリソース・アプリケーションにアクセスできます。CIMDクライアントは、内部IAM管理リソースをリクエストしたり、IAMロールを受信したりできません。

アイデンティティ・ドメインを持つIAMが保護するリソース・アプリケーションの場合、リソースにアクセスできる完全なHTTPS CIMDクライアント識別子ごとにCIMDクライアント許可リストを構成します。識別子は、OAuth client_idとして使用されるクライアント・メタデータ・ドキュメントURLです。

PATCH https://<idcs-stripe-url>/admin/v1/Apps/<app-guid>
{
  "schemas": [
    "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
    {
      "op": "add",
      "path": "cimdClientsAllowlist",
      "value": [
        "https://client.example.com/oauth/client-metadata.json",
        "https://developer.example.net/oauth/client-metadata.json"
      ]
    }
  ]
}

CIMD認可リクエストでは、次の要件を満たすリダイレクトURIを使用する必要があります。

• CIMD redirect_urisメタデータ内のすべてのリダイレクトURIを宣言します。
• HTTPSリダイレクトURIの場合、リクエストされたリダイレクトURIは宣言されたURIと完全に一致する必要があります。
• リダイレクトURIには、ユーザー情報、フラグメントまたはワイルドカードを含めることはできません。
• HTTPリダイレクトURIは、認識されたループバック・ホストに対してのみサポートされます。
• ループバック・リダイレクトURIの場合、ポートのみがredirect_urisで宣言されたURIと異なる場合があります。

たとえば、CIMDメタデータでhttp://localhost/callbackが宣言されている場合、リクエストではhttp://localhost:8000/callbackを使用できます。ポートはループバック・リダイレクトによって異なる場合がありますが、リダイレクトURIの残りは宣言されたURIと一致する必要があります。

• CIMDサポートの概要
• アイデンティティ・ドメインのCIMDの構成
• CIMD認証とトークンの例

次のサンプルは、PKCEで認可コード・フローを使用し、リフレッシュ・トークンをサポートするパブリックCIMDクライアントを示しています。

{
  "client_id": "https://client.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://client.example.com",
  "redirect_uris": [
    "http://localhost/callback",
    "http://127.0.0.1/callback"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none"
}

この例では、すべての必須CIMDメタデータ・フィールドが含まれています。token_endpoint_auth_methodはnoneであるため、パブリック・クライアントは認可コード・フローでPKCEを使用する必要があります。

アイデンティティ・ドメインがこのCIMDクライアントを信頼するように構成され、必要なリソース・アプリケーションがクライアントを認可した後、クライアントはOAuth認可フローでメタデータURLをclient_idとして使用できます。

次のサンプル認可リクエストでは、CIMD URLをclient_idとして使用します。メタデータの例ではhttp://localhost/callbackを宣言しますが、このリクエストではhttp://localhost:8000/callbackを使用します。リクエスト・リダイレクトURIは、ポートのみが異なるため、ループバック・リダイレクトに対して有効です。

https://<idcs-stripe-url>/oauth2/v1/authorize?response_type=code&client_id=https%3A%2F%2Fclient.example.com%2Foauth%2Fclient-metadata.json&redirect_uri=http%3A%2F%2Flocalhost%3A8000%2Fcallback&scope=openid+offline_access&code_challenge=<pkce-code-challenge>&code_challenge_method=S256&state=<state-value>

次のサンプルでは、認可コードをトークンと交換します。

curl --location 'https://<idcs-stripe-url>/oauth2/v1/token' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'code=<authorization-code>' \
  --data-urlencode 'grant_type=authorization_code' \
  --data-urlencode 'redirect_uri=http://localhost:8000/callback' \
  --data-urlencode 'client_id=https://client.example.com/oauth/client-metadata.json' \
  --data-urlencode 'code_verifier=<pkce-code-verifier>'

次のサンプルは、代表的なアクセストークン要求を示しています。ユーザー、テナント、ドメイン、リージョン、クライアントまたは環境を識別する値はプレースホルダを使用します。

{
  "sub": "<user-identifier>",
  "iss": "https://identity.oraclecloud.com/",
  "scope": "openid offline_access",
  "client_id": "https://client.example.com/oauth/client-metadata.json",
  "user_ocid": "ocid1.user.<realm>..<user-unique-id>",
  "client_tenantname": "idcs-<tenant-ocid>",
  "region_name": "<region-name>",
  "exp": <expiration-time>,
  "iat": <issued-at-time>,
  "client_guid": "<client-guid>",
  "client_name": "Example MCP Client",
  "aud": "https://<tenant-hostname>"
}

この表では、一般的な顧客対応クライアントIDメタデータ・ドキュメント(CIMD)エラー・シナリオ、想定される動作、およびそれらを解決するために必要な構成チェックについて説明します。

• CIMDクライアントを許可するアプリケーションの構成
• CIMDサポートの概要
• アイデンティティ・ドメインのCIMDの構成
• CIMD認証とトークンの例