mTLS によるクライアント認証

mTLS を使用してクライアントを認証する方法を説明します。

​

OAuth/OIDC における mTLS

デフォルトの OAuth/OIDC フローは、次のような理由から、必ずしも安全とは限りません。

• クライアント認証の手段として、共有の クライアントシークレット を使用すること。
• アクセストークン が意図しない第三者に使用される可能性があること。

2020 年に、Internet Engineering Task Force (IETF) は、これらの問題に対処するために RFC 8705 Mutual-TLS (mTLS) クライアント認証を公開しました。mTLS 認証では、秘密鍵を持つクライアント証明書が、OAuth/OIDC フローにおける クライアントシークレット のように機能し、クライアントの ID を検証します。クライアントがすでにネットワーク層で認証されている場合、アプリケーション層で クライアントシークレット は不要です。さらに、クライアント証明書は複数のサーバーで使用でき、リソースサーバー に対してクライアントの ID を証明できます。なお、上記の問題を解決する別の方法として、それぞれ Private Key JWT と DPoP があります。

mTLS で OAuth フローを保護するには、TLS 接続の確立時に、クライアントはカスタマーエッジネットワーク上の TLS 終端ポイントに mTLS 証明書を送信します。認可サーバー がリクエストを処理する前に、まずクライアントの mTLS 証明書を検証する必要があります。

必要に応じて、mTLS を使用して、アクセストークンが意図された当事者だけに使用されるようにすることもできます。これは 送信者制約 または Token Binding と呼ばれます。クライアントが mTLS 接続を使用して認可サーバーの /oauth/token エンドポイントを呼び出すと、生成されるアクセストークンには、クライアントの TLS 証明書がアクセストークンに対応する証明書と一致していることをリソースサーバーが検証するための情報が含まれます。

注: mTLS クライアント認証と mTLS Token Binding は、互いに独立して使用できます。mTLS クライアント認証は mTLS Token Binding なしで使用でき、mTLS Token Binding は クライアントシークレット や Private Key JWT など、他の形式のクライアント認証と組み合わせて使用できます。他の形式のクライアント認証を使用する場合でも、mTLS Token Binding のために、クライアントは引き続きクライアント証明書を認可サーバーに送信します。

​

Auth0 における mTLS

Auth0 の mTLS は、カスタムドメイン を基盤としており、証明書のプロビジョニングと検証には顧客の既存の mTLS インフラストラクチャを活用します。

通常、クライアントシークレットが必要な、認証済みクライアントから Auth0 への呼び出しは、まずカスタマーエッジに送信されます。これは、顧客管理証明書を使用する カスタムドメイン ですでに行われている方式です。カスタマーエッジはクライアントとの mTLS ハンドシェイクを実行し、クライアント証明書を検証します。クライアント証明書の検証が完了すると、リクエストは Auth0 上のテナントのエッジドメインに転送されます。このとき、カスタムドメイン機能に従って、検証済みのクライアント証明書が正しい cname-api-key とともに HTTP ヘッダーに含められます。

​

認可サーバーを呼び出す

mTLS はクライアント認証とアクセストークンのバインドの両方に使用されるため、クライアントはこれらの機能が認可サーバーで有効になっているかどうかを認識している必要があります。さらに、認可サーバーの mTLS エンドポイントと非 mTLS エンドポイントは、異なるドメインで公開される場合があります。

認可サーバーの設定の詳細を取得するには、クライアントは OpenID Connect Discovery エンドポイントに GET リクエストを送信します: https://<custom-domain>/.well-known/openid-configuration

リクエストが成功すると、OIDC ディスカバリー ドキュメント、つまり mTLS 関連の項目を含む認可サーバーのプロパティとエンドポイントを一覧化した JSON オブジェクトが返されます。

mTLS クライアント認証が有効な場合、OIDC ディスカバリー ドキュメントには token_endpoint_auth_methods_supported プロパティが含まれ、その値は tls_client_auth または self_signed_tls_client_auth のいずれかです:

{
  ...
  "token_endpoint_auth_methods_supported": ["tls_client_auth"]
  ...
}

mTLS Token Binding が有効な場合、OIDC ディスカバリードキュメントでは tls_client_certificate_bound_access_tokens プロパティが true に設定されます:

{
  ...
  "tls_client_certificate_bound_access_tokens": true
  ...
}

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",
  ...
}

エンドポイントが mtls_endpoint_aliases に記載されていない場合は、mtls_endpoint_aliases の外側に記載されている同じエンドポイントを使用します。上記の例では、pushed_authorization_request_endpoint は mtls_endpoint_aliases に記載されていません。そのため、mtls_endpoint_aliases の外側で公開されている pushed_authorization_request_endpoint (https://auth.bank.com/oauth/par) を使用します。

詳細については、RFC 8705 のエンドポイントエイリアスに関するセクションを参照してください。

​

リソースサーバーを呼び出す

クライアントがアクセストークンを受け取ると、リソースサーバー上の保護されたリソースにアクセスできます。mTLS Token Binding が有効になっている場合、認可サーバーは tls_client_certificate_bound_access_tokens プロパティを含む OIDC ディスカバリードキュメントを返します。

クライアントが mTLS にバインドされたアクセストークンを使用してリソースサーバーを呼び出すと、リソースサーバーは TLS ハンドシェイク中にクライアントに mTLS 証明書の提示を要求します。リソースサーバーは、クライアント証明書と一致しないアクセストークンを使用したリクエストを、HTTP ステータスコード 401 と invalid_token エラーコードで拒否する必要があります。詳しくは、送信者制約のためにリソースサーバーを設定するを参照してください。

​

詳しく見る

• mTLS 認証を設定する