> ## 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 Apps + SSO）
それでは、一般的な Web アプリケーションの実装を見ていきましょう。実装には ASP.NET Core を使用しており、コードは[このGitHubリポジトリ](https://github.com/auth0-samples/auth0-pnp-webapp-oidc)で確認できます。
このサンプルには、社内従業員の認証に Active Directory 連携を使用し、外部契約者には Auth0 のデータベース接続を使用するアプリケーションが含まれています。認可はルールとクレームを使って実装されており、このセクションで詳しく見ていきます。
## ユーザーログイン
Auth0 には、アプリケーションのログインコンポーネントとして利用できる Lock ウィジェットが用意されているため、独自のログイン画面を実装する必要はありません。Lock ウィジェットは、Auth0 Dashboard で設定したすべての接続 (データベース、ソーシャル、エンタープライズ) とシームレスに連携します。
Web アプリケーションと Auth0 を使用してログイン画面を実装する方法はいくつかあります。
* **Hosted Lock**: Auth0 のインフラストラクチャでホストされる Lock ウィジェットのインスタンスを使用します。
* **Embedded Lock**: アプリケーションの Web ページ内に Lock ウィジェットを埋め込みます。Lock ウィジェット自体にはいくつかのカスタマイズオプションがあり、ページ上のそれ以外の HTML は完全に自由に制御できます。
* **Custom UI**: ログイン画面用に完全に独自の Web ページを開発します。カスタム HTML フォームはサーバーに送信され、サーバー側で Authentication API を使用してユーザーを認証します。Custom UI を使用すべきケースの詳細については、[Customize Classic Login Pages with Lock or SDK](/docs/ja-jp/customize/login-pages/classic-login/customize-with-lock-sdk) を参照してください。
### Home Realm Discovery (HRD) を自動化する
デフォルトでは、Lock はログインに使用できるすべての接続を表示します。複数の選択肢から適切な Identity Providers を選ぶことを、Home Realm Discovery (HRD) と呼びます。今回のケースでは、選択肢は Active Directory で認証する (社内従業員向け) か、データベース接続でメールアドレスとパスワードを使う (外部契約者向け) かのいずれかです。
ただし、ユーザーが Identity Provider (IdP) を選択する最初のステップを省略し、毎回ユーザーに確認する代わりにシステム側で自動的に判別したい場合もあります。Lock では、次の方法を利用できます。
* **プログラムで IdP を判別する**: Auth0 で認証トランザクションを開始するときに、必要に応じて `connection` パラメータを送信できます。この値は、Dashboard で定義されているいずれかの接続に直接対応します。`/authorize` エンドポイントを呼び出して Hosted 版の Lock を使用する場合は、接続名を含む `connection` クエリ文字列パラメータを渡せます。一方、Embedded Lock を使用している場合は、`auth0.show({connections: ['{yourConnection}']});` と記述するだけです。
* `connection` の値を取得する実用的な方法はいくつかあります。その 1 つが **vanity URL** を使う方法です。たとえば、社内従業員は `https://internal.yoursite.com` を使い、外部契約者は `https://external.yoursite.com` を使います。
* **メールドメインを使用する**: Lock では、メールドメインを使って認証リクエストを振り分けることができます。Auth0 のエンタープライズ接続は `domains` にマッピングできます。接続にこの設定がある場合、対応するドメインのメールアドレスを入力すると、パスワード入力欄は自動的に無効になります。なお、1 つの接続に複数のドメインを関連付けることもできます。
このトピックの詳細については、[複数の接続オプションから選択する](/docs/ja-jp/libraries/lock/selecting-from-multiple-connection-options) を参照してください。
## セッション管理
セッション管理について説明する際には、通常、考慮すべきセッションのレイヤーが 3 つあります。
* **アプリケーションセッション**: 1 つ目は、アプリケーション内のセッションです。アプリケーションでユーザー認証に Auth0 を使用していても、ユーザーがそのアプリケーションにログイン済みであることは、引き続きアプリケーション側で管理する必要があります。一般的な Web アプリケーションでは、これは Cookie に情報を保存することで実現します。
* **Auth0 セッション**: 2 つ目は、Auth0 のセッションです。Auth0 もセッションを保持し、ユーザー情報を Cookie に保存します。次回ユーザーが Auth0 Lock 画面にリダイレクトされたときには、そのユーザー情報が保持されています。
* **Identity Provider セッション**: 最後のレイヤーは Identity Provider です。たとえば Facebook や Google です。これらのプロバイダーでのサインインを許可している場合、ユーザーがすでにそのプロバイダーにサインインしていれば、再度サインインを求められることはありません。必要に応じて、自分の情報を Auth0、ひいてはアプリケーションと共有するための権限を与えるだけで済む場合があります。
そのため、Web アプリケーションを開発する際には、ユーザーがその Web アプリケーションにログインしていることを管理する必要があります。これには、Cookie ベースのセッションを利用してサインイン状態を管理し、あわせてユーザーに関連する情報やトークンを保存します。
### ユーザーのローカルアプリケーションセッションの有効期間はどのように制御できますか？ また、それを Auth0 から制御できますか？
Web アプリは、ユーザーのローカルアプリケーションセッションを完全に制御できます。具体的な実装方法は、通常、使用している Web スタック (たとえば ASP.NET) によって異なります。とはいえ、どの方法でも最終的には 1 つ以上の Cookie を使ってセッションを制御します。開発者は、Auth0 から返される JWT ID Token の有効期限を使ってセッションの有効期間を制御することも、まったく考慮しないこともできます。ID Token 自体をセッション状態に保存し、その有効期限が切れた時点でユーザーセッションを終了させる開発者もいます。
ローカルセッションの有効期限を決める際にトークンの有効期限を使う理由は、Auth0 Dashboard からユーザーセッションの期間を一元的に制御できるためです。
ログインフローは次のとおりです。
1. **OIDC 認証フローを開始**: ユーザーのブラウザーが、OIDC フローを開始するためのリクエストを Auth0 に送信します。
2. **SSO Cookie を設定**: Auth0 がユーザー情報を保存するための Cookie を設定します。
3. **コードを交換して ID Token を返す**: Auth0 は Web サーバーにリクエストを返し、コードを返します。Web サーバーはそのコードを ID Token と交換します。
4. **認証 Cookie を設定してレスポンスを送信**: Web サーバーはブラウザーにレスポンスを返し、ユーザーのセッション情報を保存するためのアプリケーション認証 Cookie を設定します。
5. **以後のすべてのリクエストで認証 Cookie が送信される**: アプリケーション認証 Cookie は、ユーザーが認証済みであることの証明として、以後のすべてのリクエストで送信されます。
### Auth0 の SSO セッションはアプリケーションのセッションにどのような影響を与えますか？
Auth0 は独自のシングルサインオンセッションを管理しています。アプリケーションは、自身のローカルセッションを維持する際に、その SSO セッションを利用するか無視するかを選択できます。Lock ウィジェットには、Auth0 の SSO セッションが存在するかどうかを検出し、同じユーザーとして再度ログインするかをユーザーに確認する特別な機能もあります。
その場合、実際の IDP に対して認証情報を再入力しなくてもサインインできます。ユーザー自身が認証をやり直していなくても、アプリケーションは引き続き Auth0 との認証フローを実行し、新しい ID Token を取得します。これを使って、新しいローカルアプリケーションセッションを管理できます。
**実装については** [**ASP.NET Core**](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/implementation-aspnetcore#configure-the-cookie-and-oidc-middleware) **を参照してください。**
## ユーザーのログアウト
ユーザーをログアウトさせる際は、先ほど説明した 3 つのセッション層について、あらためて考える必要があります。
* **アプリケーションセッション**: セッションをクリアして、Web アプリケーションからユーザーをログアウトさせる必要があります。
* **Auth0 セッション**: Auth0 からもユーザーをログアウトさせる必要があります。これを行うには、ユーザーを `https://{yourDomain}/v2/logout` にリダイレクトします。この URL にリダイレクトすると、Auth0 がそのユーザーに設定したすべての シングルサインオン Cookie がクリアされます。
* **Identity Provider セッション**: 一般的ではありませんが、Facebook や Google など、利用している Identity Provider からユーザーを強制的にログアウトさせることもできます。これを行うには、ログアウト URL に `federated` クエリ文字列パラメーターを追加します: `https://{yourDomain}/v2/logout?federated`。
ログアウト後にユーザーをリダイレクトするには、遷移先 URL を値とする `returnTo` クエリ文字列パラメーターを追加します: `https://{yourDomain}/v2/logout?returnTo=http://www.example.com`。なお、`returnTo` URL は **Allowed Logout URLs** に追加しておく必要があります。実装方法の詳細については、[Logout](/docs/ja-jp/authenticate/login/logout) を参照してください。
ログアウトフロー (federated logout を除く) は次のとおりです。
1. **Initiate Logout Flow**: ログアウトフローはブラウザーから開始されます。たとえば、ユーザーが **Logout** リンクをクリックすると、Web サーバーにリクエストが送信されます。
2. **Clear user’s local session**: ユーザーの アプリケーションセッション / Cookie がクリアされます。
3. **Redirect browser to Auth0 Logout**: ユーザーのブラウザーが Auth0 のログアウト URL にリダイレクトされます。
4. **Clear SSO Cookie**: Auth0 がユーザーの SSO Cookie をクリアします。
5. **Redirect to post-logout URL**: Auth0 はリダイレクトレスポンスを返し、ユーザーのブラウザーを `returnTo` クエリ文字列パラメーターで指定された URL にリダイレクトします。
**実装例は** [**ASP.NET Core**](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/implementation-aspnetcore#implement-the-logout) **をご覧ください。**
## アクセス制御
認可とは、ユーザーがアプリケーション内で実行できる操作を判断するプロセスを指します。
認可は、Auth0 とは独立してアプリケーション内に直接実装することもできますし、利用可能な方法のいずれかを使ってユーザーの認可レベルを取得し、それらを ID Token 内の認可クレームとして格納して、トークン取得後にアプリケーション内でそれらのクレームを検証し、アクセスを制御することもできます。
Auth0 を使用する場合、ユーザーの認可クレームを取得して設定する方法はいくつかあります。
* [Auth0 Authorization Extension](/docs/ja-jp/customize/extensions/authorization-extension) を設定して使用する。
* Active Directory グループを使用する。これは、Active Directory グループを Authorization Extension で定義したグループにマッピングすることで、Authorization Extension と組み合わせて使用できます。
* [ルール](/docs/ja-jp/customize/rules) を利用して、ユーザープロフィールにメタデータを追加する。
* ルール 内から外部サービスを呼び出す。
このケースでは、会社ですでに Active Directory が設定されているため、Authorization Extension と Active Directory グループを組み合わせてアクセス制御を実施します。
現時点で Authorization Extension は、主に粗い粒度の認可を実現するために設計されています。たとえば、ユーザーのグループ所属に基づいてアプリケーションへのアクセスを制御する場合です。今回の例ではこのように利用していますが、必ずしもきめ細かなアクセス制御 (たとえば、ユーザーがアプリケーション内で特定の操作を実行できるかどうか) を行うために設計されているわけではありません。
すべてのユーザーは暗黙的に通常ユーザーとなりますが、タイムシート管理者は `Admin` グループに割り当てられ、タイムシートを承認できるようになります。Authorization Extension では、グループを既存のグループ所属にマッピングできます。
すべてのタイムシート管理者は、Active Directory 上の `Timesheet Administrators` グループに割り当てられ、Timesheet Application 内の `Admin` グループに自動的にマッピングされます。
Authorization Extension をインストールすると、バックグラウンドで ルール が作成され、次の処理が行われます。
1. ユーザーのグループ所属を判定する。
2. ユーザーのグループ所属情報を `app_metadata` の一部として保存する。
3. ユーザーのグループ所属を発行されるトークンに追加する。
4. ユーザーに現在のアプリケーションへのアクセス権が付与されていることを確認する。
### Authorization Extension をインストールする
Authorization Extension をインストールするには、Auth0 Dashboard の [Extensions](https://manage.auth0.com/#/extensions) ビューに移動し、Auth0 Authorization Extension を選択してインストールします。
インストールが完了すると、Installed Extensions にアプリが表示されます。
初めて拡張機能を開くリンクをクリックすると、拡張機能による Auth0 アカウントへのアクセス許可を求められます。許可すると、Authorization Dashboard にリダイレクトされます。
Authorization Dashboard が開いたら、ナビゲーションメニューの Groups に移動し、Admin という名前の新しいグループを作成します。
グループを追加したら、その新しいグループをクリックしてグループ管理セクションに移動できます。Group Mappings タブを開き、新しいグループマッピングを追加して、`Timesheet Admins` グループ内のすべての Active Directory ユーザーが、先ほど作成した `Admin` グループにマッピングされるようにします。
**Save** をクリックすると、新しいマッピングが一覧に表示されます。
このマッピングを設定すると、Active Directory の `Timesheet Admins` グループのメンバーシップを管理するだけで、それらのユーザーはアプリケーション内の `Admin` グループに自動的にマッピングされます。
詳しくは、[Authorization Extension documentation](/docs/ja-jp/customize/extensions/authorization-extension) を参照してください。
### アプリケーションで権限を適用する
Authorization Extension をインストールすると、特定のユーザーに関する認可設定をすべて含む `authorization` クレームを追加する Auth0 ルールも作成されます。ユーザーのグループは、`authorization` クレームの `groups` というサブクレームとして追加され、そのユーザーが所属するすべてのグループが配列としてこのクレームに含まれます。以下は、グループが含まれた ID Token の JSON ペイロードの例です。
```json lines theme={null}
{
"sub": "1234567890",
"name": "John Doe",
"authorization": {
"groups": ["Admin"]
}
}
```
したがって、アプリケーションでは、ユーザーの認証時に返される ID Token をデコードし、`authorization`クレームからユーザーが所属するグループを抽出する必要があります。次に、それらのグループをほかのユーザー情報とあわせてユーザーのセッションに保存し、その後それらを参照することで、ユーザーがグループへの所属に基づいて特定の操作を実行する権限を持っているかどうかを判断できます。
実装例については、[ASP.NET Core](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps/implementation-aspnetcore#implement-admin-permissions)を参照してください。