アプリケーションの資格情報

公開アプリケーションとは違って、機密アプリケーションは資格情報を安全に保管することができます。機密アプリケーションがトークンエンドポイントからアクセストークンやIDトークンを要求する場合、アプリケーションは認可サーバーで認証されなければなりません。このトークンを要求している間に、アプリケーションは、アプリケーションに既知の資格情報を提供します。さらに、アプリケーションの資格情報によって、/authorizeエンドポイントに送信された要求パラメーターの真正性と整合性を保護することができます。

機密アプリケーションとパブリックアプリケーションについては、「機密アプリケーションとパブリックアプリケーション」をお読みください。

Auth0からトークンを取得するには、アプリケーションがAuthentication APIを使って認証される必要があります。アプリケーションの認証について、Auth0は以下の方法に対応しています。

• クライアントシークレット：対称認証方法。クライアントシークレット認証では、アプリケーションを作成した際にAuth0が生成したクライアントシークレットを使用します。

• 秘密鍵JWT：非対称認証方法。秘密鍵JWTでは、公開鍵と秘密鍵をペアで生成して、資格情報として使用します。公開鍵は提供し、秘密鍵はAuth0と共有することなく、独自のシステムに安全に保管します。

• mTLS for Oauth：非対称認証方法。mTLS for OAuthでは、Auth0に標準のX.509クライアント証明書を登録します。そして、それに対応する秘密鍵を使ってmTLSトンネルを確立し、Auth0テナントのエンドポイントに要求を送信します。

クライアントシークレット認証は対称認証方法で、OAuth 2.0の仕様に含まれています。クライアントシークレット認証は、Auth0ではデフォルトの認証方法です。

この認証方法は、既存のアプリケーションやツールのすべてが対応しています。クライアントシークレットは高いエントロピーを持った値で、アプリケーションの作成時にAuth0によって生成され、アプリケーションとAuth0の両方で認識されます。アプリケーションが認証を行う際には、認可サーバーへの要求にクライアントシークレットを含めます。

クライアントシークレットを資格情報として使用することには、より高いセキュリティが求められるシナリオでは特に、セキュリティ上ある程度の危険が伴います。

• アプリケーションが使用するシークレットはAuth0と共有されます。

• シークレットはネットワークを介して送信されるため、中間者攻撃（MiTM攻撃）が起きると通信を傍受される可能性があります。

1つのアプリケーションは1つのクライアントシークレットを持つことができます。実装を新しいシークレットで更新している間は、シークレットのローテーションは行えません。詳細については、「クライアントシークレットのローテーション」をお読みください。

秘密鍵JWT認証は非対称認証方法で、秘密鍵と公開鍵という非対称鍵が使用されます。詳細については、「JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants（OAuth 2.0クライアント認証および許可付与のためのJSON Web Token（JWT）プロファイル）」をお読みください。

Auth0 DashboardまたはAuth0 Management APIを使用すると、テナントで秘密鍵JWTの使用を構成することができます。詳細については、「秘密鍵JWTの認証を構成する

秘密鍵JWTを使用する場合、認可サーバーへの要求には主に2つの手順が伴います。

1. 公開鍵と秘密鍵を構成します。

   1. 鍵のペアを生成します（1つの公開鍵と1つの秘密鍵）。

   2. 認証要求を行うアプリケーションに秘密鍵を登録し、公開鍵をIDプロバイダー（IdP）で登録します。

2. 認可サーバへの要求にアサーションを構築します。

   1. 指定したJWT形式のクレームを使用して新しいアサーションを作成し、秘密鍵で署名します。IdPに対する要求の一部にこのアサーションを含めます。

   2. IdPが公開鍵を使用してアサーションを検証します。

Auth0に秘密鍵JWTを構成する方法については、「秘密鍵JWT認証を構成する」をお読みください。秘密鍵JWTにアサーションを構築する方法については、「秘密鍵JWTを使って認証する」をお読みください。

秘密鍵を使用することには、セキュリティ上いくつかの利点があります。

• 秘密鍵はネットワークで送信されないため、アプリケーションの資格情報を暴露するリスクが軽減されます。Auth0などのIDプロバイダーは秘密鍵を知らないため、秘密鍵にアクセスできるアプリケーションのみが認証要求を作成できます。

• 署名されたアサーションは使用期限が短く、リプレイ攻撃を行う機会を制限します。

mTLS for OAuthは、自己署名証明書または公開鍵暗号基盤（PKI：Public Key Infrastructure）に基づいた相互TLS認証（mTLS：Mutual TLS）を使用して、認可サーバーに対する要求を認証します。Auth0でmTLS認証が動作する仕組みについては、「mTLSを使って認証する」をお読みください。

Auth0のmTLS for Oauthが当初に対象としていたのは、金融や医療などの高度に規制された業界で、そのような業界には高い確率でmTLSがすでに導入されていました。顧客が導入しやすいように、mTLS機能はカスタムドメインを使って構築され、証明書のプロビジョニングと検証には顧客に既存のmTLS基盤が活用されます。mTLSを用いた認証とエッジネットワークのセットアップについては、「mTLSを使用して認証する」と「カスタマーエッジをセットアップする」をお読みください。

mTLSの構成方法については、「mTLS認証を構成する」をお読みください。エッジネットワークをセットアップしてmTLSを構成すると、「認可サーバーを呼び出す」で説明されているように、アプリケーションはmTLSトンネルを確立してAuth0に要求を送信する必要があります。

mTLSでは、クライアント証明書の秘密鍵がネットワークを介して送信されないため、アプリケーションの資格情報が公開されてしまうリスクを軽減します。Auth0のようなIDプロバイダーは秘密鍵にアクセスできません。秘密鍵にアクセス可能なアプリケーションのみが認証できます。

JAR（JWT-Secured Authorization Request）はOAuth2プロトコル拡張機能で、認可要求のセキュリティを向上させます。これは、JSON Web Token（JWT）要求パラメーターを使用することで実現され、認可要求パラメーターの完全性と機密性が保護されます。

アプリケーションにJARを構成するには、Auth0 Management APIを使用します。Auth0のJAR実装には非対称暗号が使用され、ユーザーは公開鍵を登録しますが、秘密鍵は各自が安全に保管します。詳細については、「JAR（JWT-Secured Authorization Request）を構成する」をお読みください。

JARの使用では、クライアントが認可要求パラメーターを含んだJWTを作成し、秘密鍵で署名して、認可サーバーに送信します。認可サーバーはクライアントの公開鍵を使って署名を検証し、署名が有効であれば、JWTから認可要求パラメーターを抽出して、通常どおりに要求を処理します。JARの使い方については、「JAR（JWT-Secured Authorization Request）を使用した認可コードフロー」をお読みください。

1つのアプリケーションには同時に2つの公開鍵を登録することができます。Auth0は検証で正しい鍵を処理するため、運用が中断されることなくローテーションを行うことができます。以前の鍵が削除されるか無効になると、それに対応する秘密鍵で署名された要求はすべて無効になります。

注意：アプリケーションの認証と認可要求の署名について、Auth0は以下のアルゴリズムに対応しています：RS256、RS384、PS256。必ず、それらに適切な鍵を提供してください。詳細については、「秘密鍵JWT認証を構成する」と「JAR（JWT-Secured Authorization Request）を構成する」をお読みください。

同様に、mTLSクライアント証明書については、1つのアプリケーションに2つのX.509クライアント証明書（自己署名またはCA証明書のSubject DN）を同時に登録することができます。Auth0は両方のクライアント証明書を用いて検証するため、運用が中断されることなく証明書のローテーションを行うことができます。

アプリケーションの認証方法は、Auth0 Dashboardで更新することができます。詳細については、「資格情報の設定」をお読みください。

• 資格情報の設定
• 秘密鍵JWTで認証する
• 資格情報のローテーションを行う
• 秘密鍵JWT認証の設定
• mTLSで認証する