> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

<div id="mtls-in-oauthoidc">
  ## OAuth/OIDC における mTLS
</div>

デフォルトの <Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を表示" href="/ja/docs/glossary?term=OAuth">OAuth</Tooltip>/OIDC フローは、次のような理由から、必ずしも安全とは限りません。

* クライアント認証の手段として、共有の <Tooltip tip="Client Secret: クライアント（アプリケーション）が認可サーバーに対して認証するために使用するシークレットです。クライアントと認可サーバーのみが知るべきものであり、推測されないよう十分にランダムである必要があります。" cta="用語集を表示" href="/ja/docs/glossary?term=Client+Secret">クライアントシークレット</Tooltip> を使用すること。
* <Tooltip tip="Access Token: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可資格情報です。" cta="用語集を表示" href="/ja/docs/glossary?term=access+token">アクセストークン</Tooltip> が意図しない第三者に使用される可能性があること。

2020 年に、Internet Engineering Task Force (IETF) は、これらの問題に対処するために [RFC 8705](https://www.rfc-editor.org/rfc/rfc8705) Mutual-TLS (mTLS) クライアント認証を公開しました。mTLS 認証では、秘密鍵を持つクライアント証明書が、OAuth/OIDC フローにおける クライアントシークレット のように機能し、クライアントの ID を検証します。クライアントがすでにネットワーク層で認証されている場合、アプリケーション層で クライアントシークレット は不要です。さらに、クライアント証明書は複数のサーバーで使用でき、<Tooltip tip="Resource Server: 保護されたリソースをホストするサーバーです。リソースサーバーは、保護されたリソースへのリクエストを受け入れて応答します。" cta="用語集を表示" href="/ja/docs/glossary?term=resource+server">リソースサーバー</Tooltip> に対してクライアントの ID を証明できます。なお、上記の問題を解決する別の方法として、それぞれ [Private Key JWT](/ja/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) と [DPoP](https://datatracker.ietf.org/doc/html/rfc9449) があります。

mTLS で OAuth フローを保護するには、TLS 接続の確立時に、クライアントはカスタマーエッジネットワーク上の TLS 終端ポイントに mTLS 証明書を送信します。<Tooltip tip="Authorization Server: ユーザーのアクセス境界の定義に関与する集中管理サーバーです。たとえば、認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を表示" href="/ja/docs/glossary?term=authorization+server">認可サーバー</Tooltip> がリクエストを処理する前に、まずクライアントの mTLS 証明書を検証する必要があります。

<Frame>
  <img src="https://mintcdn.com/translations/pvjQqAy3EB2TK6NP/docs/images/cdy7uua7fh8z/4SlprP2uTYMCoLIPLsOl4v/d17575139419453d8772081ad20b7499/HRI_diagrams_-_mtls_diagram_1__2_.png?fit=max&auto=format&n=pvjQqAy3EB2TK6NP&q=85&s=e9b4bf1e43bb371603c0233138a12405" alt="" width="1500" height="1260" data-path="docs/images/cdy7uua7fh8z/4SlprP2uTYMCoLIPLsOl4v/d17575139419453d8772081ad20b7499/HRI_diagrams_-_mtls_diagram_1__2_.png" />
</Frame>

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

<Frame>
  <img src="https://mintcdn.com/translations/c0RQ9V0YAcT0-8l5/docs/images/cdy7uua7fh8z/7qocbfqySAnu85ph6WVSGU/ee8cd3514ed1bb6fea554cbd63d230cf/HRI_diagrams_-_mtls_diagram_2__1_.png?fit=max&auto=format&n=c0RQ9V0YAcT0-8l5&q=85&s=c50dca734167a1de3725ad42a4719bf0" alt="" width="2180" height="1530" data-path="docs/images/cdy7uua7fh8z/7qocbfqySAnu85ph6WVSGU/ee8cd3514ed1bb6fea554cbd63d230cf/HRI_diagrams_-_mtls_diagram_2__1_.png" />
</Frame>

**注**: mTLS クライアント認証と mTLS Token Binding は、互いに独立して使用できます。mTLS クライアント認証は mTLS Token Binding なしで使用でき、mTLS Token Binding は クライアントシークレット や Private Key <Tooltip tip="JSON Web Token (JWT): 2 者間で claims を安全に表現するために使用される標準の IDトークン形式（および多くの場合はアクセストークン形式）です。" cta="用語集を表示" href="/ja/docs/glossary?term=JWT">JWT</Tooltip> など、他の形式のクライアント認証と組み合わせて使用できます。他の形式のクライアント認証を使用する場合でも、mTLS Token Binding のために、クライアントは引き続きクライアント証明書を認可サーバーに送信します。

<div id="mtls-at-auth0">
  ## Auth0 における mTLS
</div>

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

通常、クライアントシークレットが必要な、認証済みクライアントから Auth0 への呼び出しは、まずカスタマーエッジに送信されます。これは、顧客管理証明書を使用する <Tooltip tip="カスタムドメイン: 特殊な、または独自の名前を持つサードパーティドメイン。" cta="用語集を表示" href="/ja/docs/glossary?term=custom+domains">カスタムドメイン</Tooltip> ですでに行われている方式です。カスタマーエッジはクライアントとの mTLS ハンドシェイクを実行し、クライアント証明書を検証します。クライアント証明書の検証が完了すると、リクエストは Auth0 上のテナントのエッジドメインに転送されます。このとき、カスタムドメイン機能に従って、検証済みのクライアント証明書が正しい `cname-api-key` とともに HTTP ヘッダーに含められます。

<Frame>
  <img src="https://mintcdn.com/translations/c0RQ9V0YAcT0-8l5/docs/images/cdy7uua7fh8z/7p3tqUtBeMAp4fBbbemhOh/379a6d3b91ad37beb8cd01a20c1b13e5/HRI_diagrams_-_mtls_diagram_3__1_.png?fit=max&auto=format&n=c0RQ9V0YAcT0-8l5&q=85&s=b590e1ff26dde96571bf65eb5a4fef6e" alt="" width="2180" height="1530" data-path="docs/images/cdy7uua7fh8z/7p3tqUtBeMAp4fBbbemhOh/379a6d3b91ad37beb8cd01a20c1b13e5/HRI_diagrams_-_mtls_diagram_3__1_.png" />
</Frame>

<div id="call-the-authorization-server">
  ## 認可サーバーを呼び出す
</div>

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

認可サーバーの設定の詳細を取得するには、クライアントは [OpenID Connect Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) エンドポイントに 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` のいずれかです:

```json lines theme={null}
{
  ...
  "token_endpoint_auth_methods_supported": ["tls_client_auth"]
  ...
}
```

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

```json lines theme={null}
{
  ...
  "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` です。

```json lines theme={null}
{
  ...
  "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 の[エンドポイントエイリアスに関するセクション](https://www.rfc-editor.org/rfc/rfc8705#name-metadata-for-mutual-tls-end)を参照してください。

<div id="call-the-resource-server">
  ## リソースサーバーを呼び出す
</div>

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

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

<div id="learn-more">
  ## 詳しく見る
</div>

* [mTLS 認証を設定する](/ja/docs/get-started/applications/configure-mtls)