> ## 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.

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

# Authenticate with mTLS

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

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

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

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

mTLS で OAuth フローを保護するには、クライアントは TLS 接続の確立時に、Customer Edge ネットワーク上の TLS 終端ポイントへ mTLS 証明書を送信します。<Tooltip tip="Authorization Server: ユーザーのアクセス範囲の境界を定義することに寄与する中央サーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=authorization+server">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 は access token が意図された当事者だけに使用されることを保証するためにも利用できます。これは 送信者制約 または Token Binding と呼ばれます。クライアントが mTLS 接続を使って認可サーバーの `/oauth/token` エンドポイントを呼び出すと、生成される access token には、リソースサーバーがクライアントの TLS 証明書とその access token に対応する証明書が一致していることを検証するための情報が含まれます。

<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 client authentication と mTLS Token Binding は、互いに独立して使用できます。mTLS client authentication は mTLS Token Binding なしで使用でき、mTLS Token Binding は Client Secret や Private Key <Tooltip tip="JSON Web Token (JWT): 2 者間でクレームを安全に表現するために使用される標準的な ID トークン形式（およびしばしば Access Token 形式）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=JWT">JWT</Tooltip> など、ほかのクライアント認証方式と組み合わせて使用することもできます。ほかのクライアント認証方式を使用する場合でも、mTLS Token Binding のために、クライアントは引き続きクライアント証明書を認可サーバーに送信します。

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

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

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

<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 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` です。

```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 のクライアント証明書を要求します。リソースサーバーは、そのクライアント証明書と一致しないアクセストークンを含むリクエストを、401 HTTP ステータスコードと `invalid_token` エラーコードで拒否する必要があります。詳細については、[Configure Resource Server for 送信者制約](/docs/ja-jp/secure/sender-constraining/configure-sender-constraining/configure-resource-server-for-sender-constraining) を参照してください。

<div id="learn-more">
  ## 詳細はこちら
</div>

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