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

> 一般的なWebアプリのシナリオにおけるソリューションの概要。

# ソリューション概要（Webアプリ + SSO）

このセクションでは、実装するソリューションの概要として、アイデンティティ管理の詳細、使用するプロトコル、必要となる認証フローについて説明します。

<div id="identity-management">
  ## アイデンティティ管理
</div>

ExampleCo は、Identity as a Service (IDaaS) プロバイダーとして Auth0 を採用することにしました。その理由は、アイデンティティ管理とアクセス管理のトレーニング、導入、運用保守に自社のリソースを割きたくなかったためです。さらに同社は今後、このソリューションを拡張し、モバイル向けネイティブアプリや、承認済みのタイムシートを社内システムに送信する API を追加する可能性も視野に入れています。Auth0 は、このような変更を最小限の労力でアーキテクチャに組み込める柔軟性を備えています。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Identity-as-a-Service (「IDaaS」) は、アイデンティティ管理とアクセス管理のためのクラウドベースのサービスです。提供されるサービスには、通常、シングルサインオン (SSO) 、フェデレーション、パスワード管理などが含まれます。
</Callout>

<div id="which-protocol-to-use">
  ## どのプロトコルを使うか
</div>

次に決めるべきなのは、どのプロトコルを使うかです。<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> と <Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC)、あるいは <Tooltip tip="Security Assertion Markup Language (SAML): パスワードなしで 2 者間の認証情報のやり取りを可能にする標準化プロトコル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=SAML">SAML</Tooltip> です。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Auth0 は、コンシューマー向け Web プロダクト (OAuth 2.0、OAuth 1.0、OpenID) にも、エンタープライズ向け導入 (SAML、WS-Federation、LDAP) にも対応する、実績ある一般的で広く使われている ID プロトコルを実装しています。ビジネスニーズに最も適したものを自由に選んで利用できます。
</Callout>

**OpenID Connect** は、OAuth 2.0 仕様群に基づく認証プロトコルです。OAuth 2.0 プロトコルを通じて渡される、シンプルな JSON の <Tooltip tip="ID Token: リソースへのアクセスではなく、クライアント自身のための資格情報。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=identity+tokens">ID トークン</Tooltip> (<Tooltip tip="ID Token: リソースへのアクセスではなく、クライアント自身のための資格情報。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=JWT">JWT</Tooltip>) を使用します。

<Info>
  ### OAuth と OpenID Connect (OIDC) の違い

  OAuth 2.0 と OpenID Connect (OIDC) は、しばしば同じものだと誤解されますが、厳密には異なります。
  **OAuth 2.0** は、ある Web サイト (コンシューマーまたはアプリケーション) に、別の Web サイト (リソースサーバーまたはプロバイダー) 上のあなたのデータへのアクセスを認可するためのプロトコルです。たとえば、ある Web サイトに Dropbox アカウント内のファイルの一部へアクセスする権限を与えたいとします。その Web サイトはあなたを Dropbox にリダイレクトし、Dropbox はその Web サイトにファイルへのアクセスを許可してよいかどうかを確認します。あなたが同意すれば、その Web サイトは Dropbox 上のファイルにアクセスする権限を得ます。要するに、OAuth 2.0 はリソースへのアクセスと共有のためのものです。
  **OpenID Connect** は、一方で、OAuth 2.0 プロトコルの上に構築されたシンプルな ID レイヤーです。これにより、複数のサイトで 1 つのログインを使えます。OIDC を使って Web サイトにログインする必要があるたびに、OpenID サイトへリダイレクトされ、そこでログインしたあと元の Web サイトに戻ります。要するに、OIDC が扱うのはユーザー認証です。
</Info>

**SAML** は XML ベースのプロトコルで、信頼関係のある当事者間で認証と認可の両方を提供します。

SAML と比べると、OpenID Connect はより軽量で扱いやすく、シンプルです。SAML は実績があり、強力で柔軟ですが、このアプリの要件ではそうした柔軟性や強力さは必要ありません。SAML を採用する大きな理由の 1 つである ID フェデレーションも、ここでは必要ありません。さらに、仮に将来それが要件になったとしても、Auth0 なら AD (LDAP を使用) を扱うのと同じように簡単に対応できます。

これらの理由から、ExampleCo は実装に OpenID Connect を使用します。

<div id="authentication-flow">
  ## 認証フロー
</div>

OpenID Connect では、認証に複数のフローを利用できます。ここでは一般的な Web アプリのシナリオを扱うため、Authorization Code Flow を使用します。

フローは次のとおりです。

1. Web アプリ (OIDC の用語では Client) は、ユーザーエージェント (ブラウザー) を Auth0 (OIDC の用語では Authorization Server) にリダイレクトして、認証リクエストを開始します。
2. Auth0 は (ユーザーエージェント経由で) ユーザーを認証します。ユーザーが初めてこのフローを実行する場合は、アプリケーションに付与される権限 (たとえば、メッセージの投稿や連絡先の一覧表示) が示された同意画面が表示されます。ユーザーはサービスにログインし (まだログインしていない場合) 、アプリケーションへのアクセスを承認します。
3. ユーザーがアクセスを許可すると、Auth0 はクエリー文字列に認可コードを付与して、ユーザーエージェントをアプリケーションにリダイレクトします。
4. アプリケーションは認可コードとアプリケーションの認証情報 (client\_id と client\_secret) を Auth0 に送信し、トークンを要求します。
5. Auth0 はアプリケーションを認証し (client\_id と client\_secret を使用) 、認可コードを検証します。有効であれば、Auth0 は ID Token を返します。

<Frame>
  <img src="https://mintcdn.com/translations/6GE5Z24GDCZehiJ9/docs/images/cdy7uua7fh8z/5qO4QJH0YW34apsypLXnIk/e27a8cf1469c00d948cc476b11b54300/authz-code-flow.png?fit=max&auto=format&n=6GE5Z24GDCZehiJ9&q=85&s=ef936f420cd15e75decb435a4285e3ee" alt="undefined" width="2094" height="1140" data-path="docs/images/cdy7uua7fh8z/5qO4QJH0YW34apsypLXnIk/e27a8cf1469c00d948cc476b11b54300/authz-code-flow.png" />
</Frame>

<Info>
  ### Form Post Response Mode

  別の方法として、`response_type=id_token&response_mode=form_post` を指定した **OAuth 2.0 Form Post Response Mode** を使用することもできます。`response_type=id_token` リクエストパラメーターにより、レスポンスには認可コードではなく ID Token が直接含まれます。一方、`response_mode=form_post` では、ID Token と残りの Authorization Response パラメーターが HTML フォームの値としてエンコードされ、User Agent で自動送信されます。この方法を使うと、認可コードを ID Token に交換する必要がないため、認証フローを最適化できます。ただし、アプリの実装に使用している技術がこれをサポートしている必要があります (ASP .NET Core middleware はサポートしています) 。詳しくは、[OAuth 2.0 Form Post Response Mode specification](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) を参照してください。
</Info>

**ID Token** (コードサンプルでは通常 `id_token` と表記されます) は、ID 情報を含む **JSON Web Token (JWT)** です。アプリケーションはこれを利用して、ユーザー名やメールアドレスなどのユーザー情報を取得し、通常は UI に表示します。

<Info>
  ### トークンについてさらに詳しく

  トークンは、トークンベース認証で使用される英数字の文字列です。これにより、ユーザーは一度ユーザー名とパスワードで認証すれば、その後は受け取ったトークンを使って認証できます。トークンの有効期間は限られています。

  **JSON Web Tokens (JWTs)** は、[JSON Web Token Standard](https://tools.ietf.org/html/rfc7519) に準拠したトークンで、クレームの形で ID に関する情報を含みます。自己完結型であるため、受信側はトークンを検証するためにサーバーへ問い合わせる必要がありません。JWT は、秘密鍵 (**HMAC** アルゴリズム) または公開鍵/秘密鍵の組を使う **RSA** で署名できます。JWT の詳細については、[こちら](/docs/ja-jp/secure/tokens/json-web-tokens) を参照してください。

  JWT である ID Token は、業界標準 (IETF [RFC 7519](https://tools.ietf.org/html/rfc7519)) に準拠しており、ヘッダー、本文、署名の 3 つの部分で構成されています。

  * ヘッダーには、トークンの種類と、トークンの内容に対して使用されたハッシュアルゴリズムが含まれます。
  * 本文は payload とも呼ばれ、ユーザーに関する ID クレームを含みます。クレームの中には登録済みの名前を持つものがあり、たとえばトークンの発行者、トークンの主体 (クレームの対象者) 、発行時刻などがあります。そのほかの名前を持つ追加のクレームも任意に加えられますが、JWT がブラウザーの URL サイズ制限を超えないよう注意が必要です。
  * 署名は、JWT の受信者が JWT に含まれる情報の完全性を検証するために使用されます。
</Info>

<div id="how-to-validate-an-id-token">
  ### ID Token を検証する方法
</div>

ID Token の検証には、いくつかの手順が必要です。

1. ID Token が暗号化されている場合は、アプリケーションが指定した鍵とアルゴリズムを使用して復号します。
2. OpenID Provider の Issuer Identifier は、`iss` (issuer) クレームの値と一致している必要があります。
3. `aud` (audience) クレームには、アプリケーションの `client_id` 値が含まれている必要があります。ID Token にアプリケーションが有効な audience として記載されていない場合、またはアプリケーションが信頼していない別の audience が含まれている場合は、その ID Token を拒否しなければなりません。
4. ID Token に複数の audience が含まれている場合、アプリケーションは `azp` クレームが存在することを確認する必要があります。
5. `azp` (authorized party) クレームが存在する場合、アプリケーションは、その値が自身の `client_id` であることを確認する必要があります。
6. アプリケーションは、JWT の `alg` ヘッダーパラメータで指定されたアルゴリズムを使用し、JWS に従って ID Token の署名を検証しなければなりません。アプリケーションは、Issuer から提供された鍵を使用する必要があります。
7. `alg` の値は、デフォルトの `RS256`、または登録時にアプリケーションが `id_token_signed_response_alg` パラメータで送信したアルゴリズムである必要があります。
8. JWT の `alg` ヘッダーパラメータで `HS256`、`HS384`、`HS512` などの MAC ベースのアルゴリズムが使用されている場合は、`aud` (audience) クレームに含まれる `client_id` に対応する `client_secret` の UTF-8 表現のオクテット列を、署名検証用の鍵として使用します。MAC ベースのアルゴリズムについては、`aud` が複数の値を持つ場合、または `aud` の値と異なる `azp` 値が存在する場合の動作は規定されていません。
9. 現在時刻は、`exp` クレームが表す時刻より前でなければなりません。
10. `iat` クレームは、現在時刻から大きく離れた時刻に発行されたトークンを拒否するために使用できます。これにより、攻撃を防ぐために nonce を保持しておく必要がある期間を制限できます。許容範囲はアプリケーションごとに異なります。
11. Authentication Request で `nonce` 値が送信されていた場合は、`nonce` クレームが存在し、その値が Authentication Request で送信された値と同一であることを確認する必要があります。アプリケーションは、リプレイ攻撃に対して `nonce` 値を確認する必要があります。リプレイ攻撃を検出する具体的な方法は、アプリケーションごとに異なります。
12. `acr` クレームが要求されていた場合、アプリケーションは、表明されたクレーム値が適切であることを確認する必要があります。
13. `auth_time` クレームが、このクレームに対する明示的な要求または `max_age` パラメータの使用によって要求されていた場合、アプリケーションは `auth_time` クレーム値を確認し、最後の End-User 認証から長時間が経過していると判断した場合は、再認証を要求する必要があります。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  ID Token をサーバーに保存する場合は、必ず安全に保存してください。
</Callout>