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

​
仕組み

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

​
Private Key JWT Client Authentication フロー

ユーザーが上流の (IdP) での認証を完了すると、認可コードとともに Auth0 にリダイレクトされます。この認可コードは、OpenID プロバイダーのトークンエンドポイントでトークンと交換されます。接続で Private Key JWT が有効になっている場合、OpenID プロバイダーのトークンエンドポイントへの呼び出しでは、より安全に認証するため、client secret の代わりに クライアントアサーション が使用されます。 以下の手順は、一般的な Private Key JWT Client Authentication フローを示しています。
Private Key JWT Client Authentication フローを示す図。
このフローを完了するには、まず Auth0 Dashboard または Management API のいずれかで、token_endpoint_auth_method=private_key_jwt を指定した新規または既存の OIDC または Okta Workforce 接続を設定する必要があります。詳しくは、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 Client Authentication を設定する

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

​
Auth0 Dashboard

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

​
Management API

Management API を使用すると、新規または既存の OIDC 接続に対して Private Key JWT Client Authentication を設定できます。
Private Key JWT Client Authentication を使用する新しい OIDC 接続を作成するには、以下の connection.options プロパティを適切に設定して、Create a Connection エンドポイントを呼び出します。POST 呼び出しの例

​
署名鍵を取得する

接続が Private Key JWT Client Authentication を使用するように設定されると、Auth0 Dashboard、Management API、または公開 JWKS URI を通じて公開鍵を取得できます。
Auth0 Dashboard から署名鍵を取得するには、次の手順に従います。
  1. Authentication > Enterprise に移動します。
  2. OpenID Connect または Okta Workforce の横にある Browse を選択します。
  3. 該当する接続を選択し、資格情報 タブを開きます。
  4. 資格情報 セクションで、該当する署名鍵の横にある Download アイコンを選択します。
Management API で公開鍵を表示するには、接続の ID を使用して Get connection keys エンドポイントを呼び出します。
このエンドポイントを使用するには、read:connections_keys スコープが必要です。
GET 呼び出しの例
レスポンス例
一部のアイデンティティプロバイダーでは、private_key_jwt 用の公開鍵を公開 JWKS (JSON Web Key Set) URI の形式で提供できます。接続用の公開鍵が生成されている場合は、次の URI を IdP の設定に追加することで取得できます。
JWKS URI はグローバル rate limits の対象になります。これらの制限に達しないよう、公開鍵をキャッシュできます。ベストプラクティスとして、Auth0 はログインのたびに JWKS URI エンドポイントを呼び出さないよう、少なくとも 5〜10 分のキャッシュ間隔を推奨しています。

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

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

キーのローテーションを理解する

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

​
詳細はこちら