> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-fix-docs-5528-php-updates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# シングルサインオンによる通常のWebアプリケーション

> OpenID Connect（OIDC）シングルサインオンを用いてユーザーを認証する通常のWebアプリの例について説明します。

この例ではExampleCoという架空の会社のためにウェブアプリケーションを作成します。当該のアプリは、ExampleCoの従業員と請負業者によって用いられるものとします。従業員は既存の企業ディレクトリ（アクティブディレクトリ）を用いる一方、請負業者は別のユーザーストアで管理されます。

<Info>
  ### TL;DR

  * Auth0は認証と認可にOAuth 2.0と<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=openid" tip="OpenID: アプリケーションがログイン情報を収集および保存することなくにユーザーのIDを検証できるようにする認証用のオープン標準。" cta="用語集の表示">OpenID Connect（OIDC）</Tooltip>のオープン標準をサポートしています（[「使用するプロトコル」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1#which-protocol-to-use)を参照）
  * OIDCがいくつかの異なる認可フローをサポートする中で、Webアプリケーションに最適なのは認可コードフローです（[「認証フロー」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1#authentication-flow)を参照）
  * アプリケーションはAuth0ではアプリケーションとして扱われます（[「アプリケーション」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2#application)を参照）
  * IDプロバイダーはAuth0では接続として扱われます（ [「接続」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2#connections)を参照）
  * Auth0はLockウィジェットを提供して、ユーザーがアプリケーションにログインできるようにしています（[「ユーザーのログイン」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#user-login)を参照してください）
  * Webアプリケーションは、ユーザーのログインを継続して追跡するために、セッションの状態を管理する必要があります。この他にも、Auth0とIDプロバイダーはセッション情報を管理しています（[「セッションの管理」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#session-management)を参照してください）。
  * それとは反対に、ユーザーをログアウトさせることにも、3つのレイヤーでセッションを管理することが関与しています（[「ユーザーのログアウト」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#user-logout)を参照してください）。
  * アクセス制御はAuth0認可拡張機能を使って管理することができます（[「アクセス制御」](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3#access-control)を参照してください）。
</Info>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  通常のWebアプリとは、主にサーバー側、ページの`GET`、`POST`、状態を維持するためのクッキーを使用するアプリを指します。他方、Web SPA（シングルページアプリ）は、クライアント側のJavaScriptコードによるAPIの呼び出しに大きく依存します。
</Callout>

## 前提条件

ExampleCoは、コンサルティングを行うスタートアップ企業です。現在、従業員は約100名で、いくつかの業務を社外の請負業者に外注しています。従業員のほとんどは企業のメインオフィスで勤務するものの、リモートで勤務するチームも一部存在します。加えて、一部の従業員は頻繁に顧客の実地へと赴き、モバイルデバイスで作業します。

従業員と請負業者は、毎週スプレッドシートのタイムシートに記入する必要があります。現状のシステムは非効率的で、同社はより優れておりかつより自動化されたソリューションへの移行が必要だと判断しました。

同社は複数の利用可能なタイムシートアプリケーションを比較し、現時点では非常にシンプルなアプリケーションを求めていたため、内製ソリューションを独自に作成するのがよりコスト効率が高いとの結論に至りました。アプリは、開発者がすでに利用しているテクノロジーであり、1週間程度で準備を整えられるため、ASP.NET Coreを用いて構築されます。

### 目標と要件

ExampleCoは、簡易的に運用を開始し、従業員からのフィードバックを集めながら構築していけるよう、新しいソリューションを素早く立ち上げることを希望しています。

アプリケーションは、ログインしているユーザーにのみが利用できるものである必要があります。各ユーザーにはロールが設けられ、このロールに基づき、特定の操作を実行でき、特定のデータを閲覧できるようにします。

<Info>
  ### 認証と認可

  ExampleCo社はユーザーをそれぞれ\_\_認証\_\_および\_\_認可\_\_したいと考えています。認証はIDに関連しており、ユーザーが主張する身元が実際に彼ら自身であることを検証することです。認可は、ユーザーがどのリソースにアクセスできるかと、それらのリソースをどのように使用できるかを決定することに関するものです。
</Info>

ExampleCoのタイムシートアプリでは、2つのロールを設ける必要があります：ユーザーと管理者：

* ユーザーロールでは、日付、勤務内容、勤務時間を指定してタイムシートに入力できます。管理者ロールも、これと同じ権限を持ちます。
* ユーザーロールでは、自分自身のタイムシートの入力内容にのみアクセスできるようにします。
* 管理者ロールでは、これに加え次のことを可能にします：

  * 他ユーザーのタイムシートの入力内容を承認または却下する。
  * 勤務内容のドロップダウンリストの値を編集できる（追加、編集、削除）。

各ユーザーには、週末までにそれぞれのタイムシートの入力が求められます。タイムシートは、毎日登録するか、週全体の内容を一度に入力するか選べます。タイムシートは、管理者により精査され、承認されます。却下された入力内容は、各従業員が更新し、再提出して承認を受けます。

同社は、全従業員のアクティブディレクトリを利用しており、従業員はアクティブディレクトリの資格情報を用いてタイムシートアプリケーションにサインインします。外部の請負業者は、ユーザーネームとパスワードを用いてサインインできます。請負業者はExampleCoの企業ディレクトリには掲載されていません。

ExampleCoは、ユーザーのログインの負荷を最小化したいと考えているものの、タイムシート入力内容の提出は承認よりリスクが低いなど、操作内容によって一定レベルのセキュリティを維持したいと考えています。ただし、承認されたタイムシートは顧客への課金に用いられるため、セキュリティは絶対必要要件となります。認証戦略は、企業の成長に合わせ適応できるよう、柔軟なものにする必要があります。例えば、管理者向けの多要素認証（<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=multifactor-authentication" tip="多要素認証（MFA）: ユーザー名とパスワードに加えて、SMS経由のコードなどの要素を使用するユーザー認証プロセス。" cta="用語集の表示">MFA</Tooltip>）などの付加的認証要件を簡単に追加できる必要があります。

会社の事務所に物理的に出勤している従業員、並びに余分なVPN接続を必要とせずリモートで勤務する従業員の両方に対応するソリューションが必要になるため、アプリはHerokuまたはMicrosoft Azureなどのクラウドプロバイダー上で導入されることになります。

<Frame>
  <img src="https://mintcdn.com/docs-dev-fix-docs-5528-php-updates/rHkjXZOPRjbdm_ng/docs/images/ja-jp/cdy7uua7fh8z/7hg1vqzNEJ2RG1JYw0pxFp/b013276bc2d4291581e5b6b9cd3c9cf5/solution-diagram.png?fit=max&auto=format&n=rHkjXZOPRjbdm_ng&q=85&s=48ff8a6595ed138995441a22c029dfea" alt="Diagram of the solution" width="750" height="408" data-path="docs/images/ja-jp/cdy7uua7fh8z/7hg1vqzNEJ2RG1JYw0pxFp/b013276bc2d4291581e5b6b9cd3c9cf5/solution-diagram.png" />
</Frame>

## もっと詳しく

* [ソリューションの概要（Webアプリ + SSO）](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-1)
* [Auth0の構成（Webアプリ + SSO）](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-2)
* [アプリケーションの実装（Webアプリ + SSO）](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-3)
* [ASP.NET Coreの実装（Webアプリ + SSO）](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/implementation-aspnetcore)
* [結論（Webアプリ + SSO）](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/part-4)