メインコンテンツへスキップ
Private Key クライアント認証 は、 Connect (OIDC) と Okta Workforce エンタープライズ接続における、クライアント認証の代替方式です。クライアント認証は通常、共有された を渡して行いますが、Private Key JWT クライアント認証 では代わりに署名付き JWT を渡すことで、アプリケーションのセキュリティを強化します。 この機能を使用すると、標準的な クライアントシークレット 認証でよく見られる、次のような一般的なセキュリティ上の問題を回避できます。
  • クライアントシークレット はリクエストごとに当事者間で送信する必要があるため、傍受や再利用のリスクが高まる。
  • 有効期限の適用や、悪意のある第三者による再利用の防止に使える仕組みが限られている。
  • 両当事者が クライアントシークレット を保持するため、漏えいや露出のリスクが高まる。
OIDC および Okta Workforce エンタープライズ接続向けの Private Key JWT クライアント認証 は、 または のいずれかで設定できます。

​
仕組み

OIDC 接続フローでは、/oauth/token や /oauth/par などの認証エンドポイントを使用して、 または OpenID プロバイダーに対してクライアントの身元を検証します。Private Key JWT クライアント認証 では、クライアントシークレットの代わりに、署名付きのクライアントアサーション JWT を OpenID プロバイダーに渡します。 クライアントアサーション JWT には、次のクレームが含まれます。
  • OpenID プロバイダーの を識別する aud () 。
  • 1 回限りの使用またはリプレイ攻撃の防止を可能にする jti (JWT ID) 。
  • トークンの有効期間を制限する exp (有効期限) 。
  • を示す sub と iss。
Private Key JWT クライアント認証 では、共有クライアントシークレットを使わないことで、より安全な認証方式を実現できます。代わりに、JWT はクライアントの秘密鍵で署名され、OpenID プロバイダーがアクセスできるのは公開鍵のみです.

​
Private Key JWT クライアント認証フロー

ユーザーがアップストリームの (IdP) での認証を完了すると、認可コードとともに Auth0 にリダイレクトされます。この認可コードは、OpenID プロバイダーのトークンエンドポイントでトークンと交換されます。接続で Private Key JWT が有効になっている場合、OpenID プロバイダーのトークンエンドポイントへの呼び出しでは、より安全に認証するため、クライアントシークレットの代わりにクライアントアサーションを使用します。 以下の手順は、一般的な Private Key JWT クライアント認証フローを示しています。
Private Key JWT クライアント認証フローを示す図。
このフローを完了するには、まず Auth0 Dashboard または Management API を使用して、token_endpoint_auth_method=private_key_jwt を指定した新規または既存の OIDC または Okta Workforce 接続を設定する必要があります。詳細については、Configure Private Key JWT Client Authentication セクションを参照してください。
  1. 接続を設定すると、Auth0 は 2 組の公開鍵と秘密鍵のペアを自動的に生成して保存します。
    • 一方の鍵ペアはアクティブな current セットで、もう一方のセットには、鍵ローテーションをサポートするため next というラベルが付けられます。
  2. 次に、IdP に応じて以下のいずれかを行います。
    • current 公開鍵をダウンロードし、そのファイルを認可サーバーにアップロードする、または
    • jwks_uri を認可サーバーにコピー＆ペーストする。
  3. ユーザーが、アプリケーションへのログインなど、認証が必要な操作を実行します。
  4. Auth0 は認証を開始するために認可サーバーへリクエストを送信します。
  5. 認可サーバーは、認証画面と同意画面をユーザーに表示します。
  6. ユーザーは認可サーバーで認証を行い、同意します。
  7. 認可サーバーは Auth0 に認可コードを送信します。
  8. Auth0 はクライアントアサーション JWT を生成し、current 秘密鍵を使用して署名します。
  9. Auth0 はクライアントアサーション JWT を認可サーバーに渡します。
  10. 認可サーバーは、指定された client_id に基づいてクライアントを特定します。
  11. jwks_uri が指定されている場合、認可サーバーは Auth0 から公開鍵を取得します。そうでない場合は、手順 2 で登録された公開鍵を特定します。
  12. jwks_uri が要求された場合、Auth0 は公開鍵を JWKS として返します。
  13. 認可サーバーは、client_assertion JWT のヘッダー内の kid で識別される current 公開鍵を使って署名を検証し、JWT を検証します。
  14. 認可サーバーはアクセストークンを生成します。
  15. 認可サーバーはアクセストークンを Auth0 に渡します。
  16. Auth0 はアクセストークンを使用して、リソースサーバーにリソースをリクエストします。
  17. リソースサーバーはリソースを返し、フローが完了します。

​
Private Key JWT クライアント認証を設定する

OIDC および Okta Workforce エンタープライズ接続で Private Key JWT クライアント認証を使用するように設定するには、Auth0 Dashboard または Management API を使用します。各方法の手順を以下に示します。
  • 秘密鍵と公開鍵の署名鍵ペアは、接続ごとに Auth0 によって自動的に生成されます。
  • クライアントアサーション JWT への署名には、Okta および OIDC エンタープライズ接続で次のアルゴリズムを使用できます: RS256, RS384, RS512, PS256, PS384, ES256, ES384。指定しない場合のデフォルトは RS256 です。
  • 署名済み JWT は 60 秒後に自動的に期限切れになります。

​
Auth0 Dashboard

Auth0 Dashboard を使用すると、新規および既存の OIDC 接続と Okta Workforce 接続の両方で、Private Key JWT クライアント認証を設定できます。
  1. Auth0 Dashboard で、Authentication > Enterprise に移動します。
  2. OpenID Connect または Okta Workforce の横にある Create を選択します。
  3. General セクションで、接続の名前やディスカバリー URL など、新しい接続の詳細を入力します。
  4. Private Key JWT を有効にするには、次の項目を設定します。
    • Communication Channel を Back Channel に設定します。
    • Authentication Method を Private Key JWT に設定します。
  5. Create を選択して、新しい接続を保存します。

​
Management API

Management API を使用すると、新規および既存の OIDC 接続に対して Private Key JWT クライアント認証 を設定できます。
Private Key JWT クライアント認証 を使用する新しい OIDC 接続を作成するには、以下の connection.options プロパティを適切に設定して、Create a Connection エンドポイントを呼び出します。
プロパティ説明
typeこのプロパティを back_channel に設定します。
token_endpoint_auth_methodIDプロバイダーのトークンエンドポイントで使用する認証方式です。署名付き JWT アサーションを使用してセキュリティを強化する場合は private_key_jwt に、リクエスト本文で認証情報を送信する場合は client_secret_post に設定します。デフォルトは client_secret_post です。oidc および okta ストラテジーにのみ適用されます。
token_endpoint_auth_signing_alg任意。クライアントアサーションの署名に使用するアルゴリズムです。使用可能な値: RS256、RS384、RS512、PS256、PS384、ES256、ES384。未設定の場合のデフォルトは RS256 です。oidc および okta ストラテジーにのみ適用されます。
id_token_signed_response_algs任意。IDプロバイダーが発行した IDトークン の検証に使用できるアルゴリズムの一覧です。設定すると、Auth0 はこの一覧に含まれないアルゴリズムで署名された IDトークン を拒否します。使用可能な値: RS256、RS384、RS512、PS256、PS384、ES256、ES384。未設定の場合、Auth0 はサポートされている任意のアルゴリズムで署名された IDトークン を受け入れます。oidc および okta ストラテジーにのみ適用されます。
token_endpoint_jwtca_aud_format任意。トークンエンドポイントでのクライアント認証に使用する JWT の aud (対象者) クレームの形式を指定します。OIDC の issuer URL を使用する場合は issuer に、トークンエンドポイント URL を使用する場合は token_endpoint に設定します。デフォルトは token_endpoint です。
POST 呼び出しの例
POST /api2/connections

{
  strategy: 'oidc',
  options: {
    type: "back_channel",
    token_endpoint_auth_method: "private_key_jwt",
    token_endpoint_auth_signing_alg: "RS256",
    id_token_signed_response_algs: ["RS256", "RS384"]
  },
  …
}

​
署名鍵の取得

接続が Private Key JWT クライアント認証 を使用するように設定されると、Auth0 Dashboard、Management API、または公開 JWKS URI を介して公開鍵を取得できます。
Auth0 Dashboard から署名鍵を取得するには、次の手順を実行します。
  1. Authentication > Enterprise に移動します。
  2. OpenID Connect または Okta Workforce の横にある Browse を選択します。
  3. 対象の接続を選択し、Credentials タブを開きます。
  4. Credentials セクションで、該当する署名キーの横にある Download アイコンを選択します。
Management API で公開鍵を表示するには、接続の ID を使用して Get connection keys エンドポイントを呼び出します。
このエンドポイントを使用するには、read:connections_keys スコープが必要です。
GET 呼び出しの例
GET /api2/connections/{id}/keys
レスポンス例
{
    cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBAgIJP...Ek=
-----END CERTIFICATE-----",
    pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQcCo...AA==
-----END PKCS7-----
",
    kid: "E4CXqUP6r92yo0f_sdkdC",
    next: true,
    fingerprint: "7F:33:86:D9:4A:98:B2:DC:B0:41:74:54:DA:31:E7:74:42:32:96:8C",
    thumbprint: "7F3386D94A98B2DCB0417454DA31E7744232968C"
  }, 
  {
    cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBAgI...Ss=
-----END CERTIFICATE-----",
    pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQ...AA==
-----END PKCS7-----
",
    kid: "_4WuXpXlwwmSE65saKWDM",
    current: true,
    current_since: "2025-01-24T08:50:06.662Z",
    fingerprint: "33:7D:6F:35:46:31:AD:6E:69:43:01:A2:77:DF:8E:73:64:F6:E8:5B",
    thumbprint: "337D6F354631AD6E694301A277DF8E7364F6E85B"
  }, 
  {
    cert: "-----BEGIN CERTIFICATE-----
MIIDDTCCAfWgAwIBA...6Q=
-----END CERTIFICATE-----",
    pkcs7: "-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcN...AA==
-----END PKCS7-----
",
    kid: "roUD9STeDy9qBTx5XjaTz",
    previous: true,
    current_since: "2025-01-24T08:48:51.523Z",
    current_until: "2025-01-24T08:50:06.663Z",
    fingerprint: "44:D3:DD:3B:63:99:59:9A:39:D9:F4:F0:4F:1B:AC:BB:18:72:40:5C",
    thumbprint: "44D3DD3B6399599A39D9F4F04F1BACBB1872405C"
  }
一部の IDプロバイダー では、private_key_jwt 用の公開鍵を公開 JWKS (JSON Web Key Set) URI の形式で提供できます。接続の公開鍵が生成されている場合は、次の URI を IdP の設定に追加することで取得できます。
https://{auth0 domain}/oauth/connection/{connection name}/.well-known/jwks.json
JWKS URI はグローバルなレート制限の対象です。これらの制限に達しないよう、公開鍵をキャッシュできます。ベストプラクティスとして、Auth0 では、ログイン試行のたびに JWKS URI エンドポイントを呼び出さないよう、少なくとも 5～10 分のキャッシュ間隔を推奨しています。

​
署名鍵をローテーションする

Private Key JWT クライアント認証 は、共有クライアントシークレットのように固定的で長期間有効な認証情報と比べて、より高いセキュリティを実現するために署名鍵のローテーションをサポートしています。署名鍵をローテーションすると、1 つの鍵がさらされる期間を限定できるため、攻撃者に侵害されるリスクを低減できます。また、セキュリティインシデント発生時にも迅速に対応できます。 サービスへの影響を避けるため、Auth0 では署名鍵を 1 年ごとにローテーションすることを推奨しています。署名鍵のローテーションには、Auth0 Dashboard または Management API を使用できます。
Auth0 Dashboard で署名鍵をローテーションするには、次の手順に従います。
  1. Authentication > Enterprise に移動します。
  2. OpenID Connect または Okta Workforce の横にある Browse を選択します。
  3. 対象の接続を選択し、Credentials タブを開きます。
  4. Credentials セクションで、Rotate Keys を選択します。
  5. ポップアップで Save を選択し、ローテーションを確定します。
ローテーション後は、以前の鍵で署名された処理中の JWT は直ちに無効となり、IdP での検証に失敗する可能性があります。
Management API で公開鍵を表示するには、接続の ID を使用して Rotate Connection Signing Keys エンドポイントを呼び出します。
このエンドポイントを使用するには、create:connections_keys と update:connections_keys の両方のスコープが必要です。
POST /v2/connections/{id}/keys/rotate
ローテーション後は、以前の鍵で署名された処理中の JWT は直ちに無効となり、IdP での検証に失敗する可能性があります。

鍵ローテーションの仕組みを理解する

OIDC または Okta Workforce の接続では、署名鍵に次のいずれかのステータスが割り当てられます。
  • Current: 現在アプリケーションで使用されている署名鍵。
  • Next: 現在の鍵が失効した後に、アプリケーションで次に使用される署名鍵。
  • Previous: 期限切れ、またはその他の理由で失効し、現在は使用されていない署名鍵。
接続で Private Key JWT クライアント認証 を最初に有効にした時点では、current と next のキーペアのみが生成されます。鍵が previous としてマークされるのは、ローテーションが実行された後です。署名鍵をローテーションすると、次の変更が発生します。
  1. current 鍵は削除されて失効し、この鍵で署名された JWT は、IdP が jwks_uri で設定されている場合、IdP での検証に失敗します。
  2. current 鍵には previous ステータスが割り当てられます。
  3. next 鍵がアクティブな鍵となり、current ステータスが付与されます。以後、クライアントアサーション JWT はこの鍵で署名されます。
  4. ローテーションされた鍵を置き換えるために、新しい署名鍵が自動的に生成されます。新しい署名鍵には next ステータスが付与されます。

​
詳しくはこちら