クライアントのmTLS認証の構成
Management APIとAuth0 DashboardでクライアントのmTLS認証を構成する方法を学びましょう。
Auth0 Dashboardを使用して、クライアントに対するmTLSを構成し、認可サーバーに対してmTLSクライアント認証を有効にすることができます。
［Auth0 Dashboard］ > ［Applications（アプリケーション）］ > ［Applications（アプリケーション）］に移動します。
mTLSで使用したいアプリケーションを選択するか、または新しいアプリケーションを作成します。
［Credentials（資格情報）］タブを選択します。
必要な［Authentication Method（認証方法）］を選択します。どちらも使用できます：
自己署名付き証明書のあるmTLS
認証局署名の証明書のあるmTLS
希望する証明書タイプを選択すると、次のことができます：
既存の資格情報（証明書）のクライアントアプリケーションへの割り当て
証明書のアップロードによる新しい資格情報の追加
Auth0 Management APIを使用して、クライアントにmTLSを構成します。
以下の例では、$management_access_tokenまたはManagement APIのアクセストークンを指定します。これは、少なくとも以下のスコープを含むアクセストークンで置き換えなければなりません。
create:custom_domainsread:custom_domainscreate:clientsupdate:clientsupdate:client_credentialsupdate:client_keysupdate:tenant_settings
必要なスコープを含んだアクセストークンの取得については、「 アクセストークンを取得する」をお読みください。
自己署名証明書
自己署名証明書を使用して、mTLS認証中にクライアントのIDを検証します。ただし、自己署名証明書には次の制限があります。
自己署名証明書は、Amazonなど、一部のクラウドプロバイダーは受け入れません。
プラットフォームの安定性を確保するため、Auth0は登録できる証明書を2つまでに制限しています。
証明書を生成する
自己署名のあるmTLSを使用して認証するには、クライアントに新しい自己署名証明書を作成する必要があります。
以下のサンプルコードは新しい自己署名証明書を作成します。
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 365 -nodes -subj "/C=XX/ST=StateName/L=CityName/O=CompanyName/OU=CompanySectionName/CN=CommonNameOrHostname"Was this helpful?
curlまたはWgetを使用する場合、PEM証明書をAuth0に渡す前にJSONでエスケープ処理する必要があります。たとえば、以下のように改行を \r\nに置き換えます。
-----BEGIN PRIVATE KEY-----\r\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDDXAVKQo2SUMHH\r\no9ecWYNiL5\/yva5NSj8uQjKoeRAsOIOAyOBTLxgwmno13xZ8VDkcT1cHTlC+2CkE\r\noBII4OUbHPVof+dtknkL+jUBdIPX1QvlGSUbzduZE4hEEQ8zH6w4EAA2VN72Bymn\r\nT8i\/+Tz9Dx6M1nkuXPCwM7sYEuq5OrqT5yVB6KByKKElp\/tauJkHp0st04iGDgl2\r\nFJUt3QJFCFewTDDdGq62otVJxHfouXPmHBQjzf+f1CZy+N0q2z+JGRt44YZq+F9y\r\ne3RWawvv2x3TXgRBLpvIKqf99LoPVdwozHl8QODu52dyelvLQ866XLhAALuMwic\/\r\nbQbolnMpAgMBAAECggEAf6LliekFmezNTmQLgIkzP7kh5XRsJu81bEGv20aNfHbH\r\n5CJZ\/b8tLMQgyIWiqURVs9taXtmaA7YyxmTWo5pb1WUMKWQ3je0+zMaCTxsS8Lau\r\n+NV+2zWaHd8XDnGe3qX43QAHQ3gb294+JqQH4vUyFZwFN7sAnXv3fQevW0Ewvics\r\nOua\/xNa7y5hbJUPZiQjRhO+n+gTEqpfsnPWNlm9hk\/wVnnjKvMfstN4zUbznRAoN\r\nW8TK82tiVWAXW4CjgIBtVRZjTA9x3UOtbhcvNzaTRxc+scCpIpAVuurS+ZIKZdpm\r\nNnhiOk3akpLU3KZrm8C5JQRn8cupY9WkfCiLXbMFAQKBgQD9JfVMv6zDeNvExneR\r\n7fZDIT2UAEhYExwRJwQPyxkVPwev9HBYuuaaknIbomWTkt\/B6Q3k3p6VI4lxhnVl\r\nbkpOYl5UquP3VoVROEJts224hKgVcLw6s+i+lZDOAleNgbN7rj82l4BIu+SEj\/7c\r\nz94hAa\/wRRvsW+QnxF1sZnpY+QKBgQDFj2h8I4noFJk3sbbk3qQdi5+49ibWSuhc\r\nXVpU+0dQ1lRlhXYT9cDMc22HRt8hjXUNRhdpXvOqVaFiBjv9wBsmFyaJO3tOK3uE\r\ndBgD4lF03bnbGI7\/I3DivW\/tyEMS5JXI\/qrpdWor+wR30c5M\/45y2AGpjwnoGf+D\r\nX8SAMzknsQKBgQCrSljuIrBK3+eNAWH821CL4d0h3QMWnW+bZ5QG\/70sNCcGd1bh\r\noy3Qn5EYg81JitNfCUw+dihF7\/LbX0jmZjdfTI5Zqfxw6xlweKnyQrvWY+S8BTlI\r\nW138P4Xo74rAlGeXI7NgRCkojgK1dB3W2cyK9vJOmOSpDRCXm\/Y\/GCRnOQKBgCE\/\r\n75\/lA1LSFK9w8401g32NgEZK92JdnRnehFOFLw2F5RJpEeRuGhLO4oJABVHKUwb2\r\n4v3TA0OJwe2Tiwk8CdWxU8UJA8m2O8WhHGGa94apwpwDWB3MwzUGGQ52BAPsAOGh\r\nKva70jCwwKHB5+zBniHqBO2aq1oq9fwQZCwHcvkhAoGBAIa8QMHNrX7AuCSAeR4\/\r\n\/7XrGU1a4oExz417AYgZOuGaYQAI5BMIjRZZ3JTzO\/QsmkzeS1tFuBlih8li\/t4l\r\nE2TdnKhy376A6QWfbTDkJN6gzFeaMKwe98mOHKeq0KZITGYVTSa2AYH5zaro0Yku\r\nonOH1NdyEKFFgxGLg7wveYUW\r\n-----END PRIVATE KEY-----Was this helpful?
新しいクライアントを作成する
新しいクライアントを作成するには、以下のペイロードを使用して/clientsエンドポイントにPOST呼び出しを行います。
$client_name：新しいクライアントの名前$credential_name：公開鍵の名前$credential_certificate：前の手順で生成された$certificate_pemの内容
curl --location --request POST 'https://$tenant/api/v2/clients' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "$client_name",
"app_type": "non_interactive",
"client_authentication_methods": {
"self_signed_tls_client_auth": {
"credentials": [{
"name": "$credential_name",
"credential_type": "x509_cert",
"pem": "$credential_certificate"
}]
}
},
"jwt_configuration": {
"alg": "RS256"
}
}'Was this helpful?
詳細については、クライアント作成APIのドキュメントを参照してください。
既存のクライアントにパッチを適用する
token_endpoint_auth_methodフィールドのすべての値を削除し、client_authentication_methodsフィールドに値を作成することで、mTLSクライアント認証を受け入れるように既存のクライアントを更新することができます。
mTLSに対してクライアントを構成すると、mTLSの使用を停止するためにtoken_endpoint_auth_methodを構成しない限り、クライアントシークレットを使用して認証することはできなくなります。詳細については、「クライアントシークレットの使用を可能にするクライアントの復元」をお読みください。
資格情報リソースを作成する
証明書を生成した後に、資格情報リソースを作成します。
curl --location --request POST 'https://$tenant/api/v2/clients/$client_id/credentials' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "$credential_name",
"credential_type": "x509_cert",
"pem": "$credential_certificate"
}'Was this helpful?
Auth0は応答で資格情報IDを返し、これをクライアントで資格情報に関連付ける必要があります。
詳細については、クライアント資格情報作成APIのドキュメントを参照してください。
クライアントに資格情報を関連付けて、token_endpoint_auth_methodを無効にする
アップロードされた資格情報は、自動的にクライアント認証に有効化されません。クライアントの新しい自己署名証明書を使用するように、クライアント認証を更新する必要があります。
以下のPATCH要求は、token_endpoint_auth_methodをnullに設定して、クライアントのシークレット認証を無効にします。また、資格情報IDでclient_authentication_methodsを更新します。
curl --location --request PATCH 'https://$tenant/api/v2/clients/$client_id' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"token_endpoint_auth_method": null,
"client_authentication_methods": {
"self_signed_tls_client_auth": {
"credentials": [{ "id": $credential.id }]
}
}
}'Was this helpful?
この要求が完了すると、クライアントシークレットが無効になるため、クライアントはmTLSを使用して認証する必要があります。
詳細については、クライアント更新APIのドキュメントを参照してください。
認証局署名の証明書
クライアント生成の信頼チェーンを持たない自己署名証明書とは異なり、認証局（CA）署名証明書は、信頼されるサードパーティーが発行するため、信頼性が高くなります。CA署名証明書は、Amazonなど、いくつかのクラウドプロバイダーが受け入れる唯一の証明書タイプです。
CA署名証明書には、識別情報に識別名（DN）の概念が埋め込まれています。特定のCAが作成する証明書はそれぞれ一意であるため、同じDNを共有することができます。CA署名証明書の使用では、Auth0はDNを保管して、転送されたクライアント証明書を登録済みのDNで照合します。
証明書を生成する
クライアントのCA署名証明書を生成する方法は、公開鍵のインフラストラクチャに大きく依存するため、このドキュメントでは扱いません。少なくとも 2048ビットのRSAキーペアの生成をお勧めします。
新しいクライアントを作成する
クライアントを作成するには、/clientsエンドポイントのPOSTを呼び出しに以下のペイロードを使用します。
$client_name：新しいクライアントの名前$credential_name：公開鍵の名前$credential_certificate：CAが生成した$certificate_pemの内容
curl --location --request POST 'https://$tenant/api/v2/clients' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "$client_name",
"app_type": "non_interactive",
"client_authentication_methods": {
"tls_client_auth": {
"credentials": [{
"name": "$credential_name",
"credential_type": "cert_subject_dn",
"pem": "$credential_certificate"
}]
}
},
"jwt_configuration": {
"alg": "RS256"
}
}'Was this helpful?
完全なPEMファイルを渡す代わりに、サブジェクト識別名を渡すこともできます。サブジェクト識別名は、mTLSハンドシェイクで送信されたクライアント証明書から抽出した識別名（DN）と一致しなければなりません。
サブジェクト識別名の抽出は、エコシステムによって異なる可能性があります。認可サーバーとサブジェクト識別名を確実に一致させるには、PEMファイル全体をアップロードします。
以下のPOST要求は、サブジェクト識別名を使用して新しいクライアントを作成します。
curl --location --request POST 'https://$tenant/api/v2/clients' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "$client_name",
"app_type": "non_interactive",
"client_authentication_methods": {
"tls_client_auth": {
"credentials": [{
"name": "$credential_name",
"credential_type": "cert_subject_dn",
"subject_dn": "C=XX\nST=StateName\nL=CityName\nO=CompanyName\nOU=CompanySectionName\nCN=CommonNameOrHostname"
}]
}
},
"jwt_configuration": {
"alg": "RS256"
}
}'Was this helpful?
既存のクライアントにパッチを適用する
mTLSを使用する新しいクライアントを作成したくない場合には、mTLSクライアント認証を受け入れるように既存のクライアントを更新できます。これを行うには、token_endpoint_auth_methodフィールドのすべての値を削除して、client_authentication_methodsフィールドに値を作成する必要があります。
mTLSに対してクライアントを構成すると、mTLSの使用を停止するためにtoken_endpoint_auth_methodを構成しない限り、クライアントシークレットを使用して認証することはできなくなります。詳細については、「クライアントシークレットの使用を可能にするクライアントの復元」をお読みください。
資格情報リソースを作成する
mTLS専用のキーペアを生成したら、資格情報リソースを作成します。 /clientsエンドポイントに以下のPOST要求を行います。
curl --location --request POST 'https://$tenant/api/v2/clients/$client_id/credentials' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "$credential_name",
"credential_type": "cert_subject_dn",
"pem": "$credential_certificate"
}'Was this helpful?
完全なPEMファイルを渡す代わりに、サブジェクト識別名を渡すこともできます。サブジェクト識別名は、mTLSハンドシェイクで送信されたクライアント証明書から抽出した識別名（DN）と一致しなければなりません。
今のサンプルコードは、サブジェクト識別名を使用して新しいクライアントを作成します。
curl --location --request POST 'https://$tenant/api/v2/clients/$client_id/credentials' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"name": "$credential_name",
"credential_type": "cert_subject_dn",
"subject_dn": "C=XX\nST=StateName\nL=CityName\nO=CompanyName\nOU=CompanySectionName\nCN=CommonNameOrHostname"
}'Was this helpful?
どちらの方法を使用する場合でも、応答で返される資格情報IDは、クライアントで資格情報と関連付けなければならないことに注意してください。
詳細については、クライアント資格情報作成APIのドキュメントを参照してください。
クライアントに資格情報を関連付けて、token_endpoint_auth_methodを無効にする
これで資格情報は作成しましたが、まだ資格情報をクライアントと関連付けていません。
関連付けるには、/clients エンドポイントに以下のPATCH要求を行って、client_authentication_methodsを更新します。同じ要求で、token_endpoint_auth_method をnullに設定します。
curl --location --request PATCH 'https://$tenant/api/v2/clients/$client_id' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"token_endpoint_auth_method": null,
"client_authentication_methods": {
"tls_client_auth": {
"credentials": [{ "id": $credential.id }]
}
}
}'Was this helpful?
この要求が完了すると、クライアントはmTLSのみで認証可能になります。
詳細については、クライアント更新APIのドキュメントを参照してください。
クライアントシークレットの使用にクライアントを復元する
クライアントシークレットを使って認証するようにクライアント構成を復元するには、client_authentication_methodsを無効にし、希望の認証方法でtoken_endpoint_auth_methodを再度有効化します。
以下のPATCH要求で、token_endpoint_auth_methodをclient_secret_postに設定して、クライアントシークレット認証を再度有効化します。
curl --location --request PATCH 'https://$tenant/api/v2/clients/$client_id' \
--header 'Authorization: Bearer $management_access_token' \
--header 'Content-Type: application/json' \
--data-raw '{
"token_endpoint_auth_method": "client_secret_post",
"client_authentication_methods": null
}'Was this helpful?
詳細については、クライアント更新APIのドキュメントを参照してください。