Authenticate with mTLS

共有のクライアントシークレットを X.509 証明書に置き換え、必要に応じてアクセストークンをクライアントにバインドすることで、相互 TLS（mTLS）が OAuth フローを保護する仕組みを学びます。

​

OAuth/OIDC における mTLS

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

• クライアント認証の手段として、共有された Client Secret を使用すること。
• access token が、本来想定されていない第三者にも使われる可能性があること。

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

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

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

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

​

Auth0 における mTLS

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

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

​

認可サーバーを呼び出す

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 endpoint aliases をサポートする環境では、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 のクライアント証明書を要求します。リソースサーバーは、そのクライアント証明書と一致しないアクセストークンを含むリクエストを、401 HTTP ステータスコードと invalid_token エラーコードで拒否する必要があります。詳細については、Configure Resource Server for 送信者制約 を参照してください。

​

詳細はこちら

• mTLS認証を設定する