mTLSで認証する
OAuth/OIDCのmTLS
デフォルトのOAuth/OIDCフローは、以下の問題から、常に安全であるとは限りません。
共有クライアントシークレットがクライアント認証の形式に使用されている
アクセストークンが意図しない当事者によって使用される
2020年に、Internet Engineering Task Force（IETF）は、こうした問題に対処するために、RFC 8705の「Mutual-TLS (mTLS) Client Authentication」（相互TLS（mTLS）を利用したクライアント認証）をリリースしました。mTLSを利用した認証では、秘密鍵を持つクライアント証明書は、OAuth/OIDCフローのクライアントシークレットのように機能し、クライアントのIDを確認します。クライアントがネットワーク層ですでに認証されている場合、アプリケーション層でクライアントシークレットは必要ありません。さらに、クライアント証明書を複数のサーバーに使用することで、リソースサーバーにクライアントのIDを証明することができます。上記の問題を解決する方法はこの他にもあります。その名前は秘密鍵JWTとDPoPです。
OAuthフローをmTLSで保護するために、クライアントはTLS接続の確立時に、mTLS証明書を顧客のエッジネットワーク上のTLS終端ポイントに送信します。認可サーバーは要求を処理する前に、クライアントのmTLS証明書をまず確認する必要があります。
また、mTLSを使用すると、意図された当事者のみがアクセストークンを使用する（送信者制限またはトークンバインディングと呼ばれる）ことができます。クライアントがmTLS接続を使用して認可サーバーの/oauth/tokenエンドポイントを呼び出すと、クライアントのTLS証明書がアクセストークンの証明書に一致することを確認するためにリソースサーバーが使用する情報が、アクセストークンに含まれることになります。
注意：mTLSクライアント認証とmTLSトークンバインディングは、それぞれ単独で使用することができます。mTLSクライアント認証はmTLSトークンバインディングなしで使用でき、mTLSトークンバインディングはクライアントシークレットや秘密鍵JWTなど他の形式のクライアント認証と併用することができます。他の形式のクライアント認証を使用している場合でも、クライアントはクライアント証明書をmTLSトークンバインディングの認可サーバーに送信します。
Auth0でのmTLS
Auth0のmTLSはカスタムドメインを使って構築され、証明書のプロビジョニングと検証には顧客に既存のmTLS基盤が活用されます。
クライアントシークレットを通常必要とするAuth0への認証済みクライアント呼び出しは、まず、カスタマーエッジに送信されます。このアクションは、顧客が管理する証明書を使用するカスタムドメインではすでに起こっています。カスタマーエッジはクライアントとmTLSハンドシェイクを実行し、クライアント証明書を検証します。クライアント証明書が検証されたら、カスタムドメインの機能に基づいて、要求がAuth0でテナントのエッジドメインに転送されます（HTTPヘッダー内の検証済みクライアント証明書と正しいcname-api-keyを含む）。
認証サーバーを呼び出す
mTLSはクライアント認証とアクセストークンバインディングの両方を処理するため、クライアントはこれらの機能が認可サーバーで有効かどうか知っている必要があります。さらに、認可サーバーのmTLSエンドポイントと非mTLSエンドポイントは、異なるドメインに公開されることがあります。
認可サーバーの構成詳細を取得するために、クライアントはGET要求をOpenID Connect Discoveryエンドポイントhttps://<custom-domain>/.well-known/openid-configurationに送信します。
応答に成功すると、OIDCディスカバリードキュメントまたはJSONオブジェクトが返され、認可サーバーのプロパティとエンドポイント（mTLSに関連するものを含む）が一覧表示されます。
mTLSクライアント認証が有効な場合、OIDCディスカバリードキュメントにはtoken_endpoint_auth_methods_supportedプロパティが含まれます。このプロパティには、tls_client_authまたはself_signed_tls_client_authが含まれています。
{
...
"token_endpoint_auth_methods_supported": ["tls_client_auth"]
...
}Was this helpful?
mTLSトークンバインディングが有効な場合、OIDCディスカバリードキュメントはtls_client_certificate_bound_access_tokensプロパティをtrue:に設定します。
{
...
"tls_client_certificate_bound_access_tokens": true
...
}Was this helpful?
mTLSエンドポイントエイリアスをサポートする環境では、mTLSをサポートするエンドポイントのリストを含む新しいプロパティmtls_endpoint_aliasesが公開されます。mTLSをサポートするクライアントの場合、mtls_endpoint_aliasesに表示されたエンドポイントが、mtls_endpoint_aliasesの外で公開された同じエンドポイントよりも優先されます。
以下のコードサンプルでは、token_endpointプロパティが2回公開されています。mTLSの呼び出しに使用するエンドポイントは、mtls_endpoint_aliasesまたはhttps://mtls.auth.bank.com/oauth/tokenに一覧表示されています。
{
...
"mtls_endpoint_aliases": {
"token_endpoint": "https://mtls.auth.bank.com/oauth/token"
},
"token_endpoint": "https://auth.bank.com/oauth/token",
"pushed_authorization_request_endpoint": "https://auth.bank.com/oauth/par",
...
}Was this helpful?
エンドポイントがmtls_endpoint_aliasesに一覧表示されていない場合は、mtls_endpoint_aliasesの外に一覧表示された同じエンドポイントを使用してください。上記の例では、pushed_authorization_request_endpointはmtls_endpoint_aliasesに一覧表示されていません。そのため、mtls_endpoint_aliasesまたはhttps://auth.bank.com/oauth/parの外に公開されたpushed_authorization_request_endpointを使用します。
詳細については、RFC 8705のエンドポイントに関するセクションを参照してください。
リソースサーバーを呼び出す
クライアントはアクセストークンを受け取ったら、リソースサーバーで保護されたリソースにアクセスすることができます。mTLSトークンバインディングが有効な場合、認可サーバーはtls_client_certificate_bound_access_tokensプロパティを含むOIDCディスカバリードキュメントを返します。
クライアントがmTLSバウンドアクセストークンを使ってリソースサーバーを呼び出す場合、リソースサーバーはTLSハンドシェイク中にクライアントからmTLS証明書を要求します。リソースサーバーは、クライアント証明書が401 HTTPステータスコードとinvalid_tokenエラーコードに一致しないアクセストークンを持つ要求を拒否する必要があります。詳細については、「送信者制限用にリソースサーバーを構成する」をお読みください。