アプリケーション実装（Web アプリ + SSO）

Regular Web Application シナリオのアプリケーション実装

それでは、Regular Web Application の実装を見ていきましょう。実装には ASP.NET Core を使用しており、コードは この GitHub リポジトリ で確認できます。

このサンプルには、社内従業員の認証に Active Directory 統合を使用し、外部委託業者向けには Auth0 のデータベース接続を使用するアプリケーションが含まれています。認可は、以降で詳しく説明するように、Rules とクレームを使用して実装されています。

​

ユーザーログイン

Auth0 は、アプリケーションのログインコンポーネントとして利用できる Lock ウィジェットを提供しています。これにより、独自のログイン画面を実装する必要はありません。Lock ウィジェットは、Auth0 Dashboard で設定したすべての接続 (データベース接続、ソーシャル接続、エンタープライズ接続) とシームレスに統合されます。

Web アプリケーションと Auth0 を使用してログイン画面を実装する方法はいくつかあります。

• ホスト型 Lock: Auth0 のインフラストラクチャでホストされる Lock ウィジェットのインスタンスを使用します。
• 埋め込み型 Lock: アプリケーションの Web ページ内に Lock ウィジェットを埋め込みます。Lock ウィジェット自体にはいくつかのカスタマイズオプションがあり、ページ上のその他の HTML は完全に制御できます。
• カスタム UI: ログイン画面用に完全に独自の Web ページを開発します。カスタム HTML フォームはサーバーに POST され、サーバー側で Authentication API を使用してユーザーを認証します。カスタム UI を使用するタイミングの詳細については、Lock または SDK を使用した Classic Login ページのカスタマイズ を参照してください。

​

Home Realm Discovery (HRD) を自動化する

デフォルトでは、Lock はログインに使用できるすべての接続を表示します。複数の選択肢から適切な IDプロバイダー を選択することを、Home Realm Discovery (HRD) と呼びます。ここでの選択肢は、Active Directory で認証する (社内従業員向け) か、データベース接続でメールアドレス/パスワード認証を使用する (外部委託先向け) かのいずれかです。

ただし、ユーザーが IDプロバイダー (IdP) を選択する最初のステップを省き、毎回確認する代わりにシステム側で自動的に判別したい場合もあります。Lock では、次のオプションを利用できます。

• プログラムで IdP を識別する: Auth0 で認証トランザクションを開始する際に、必要に応じて connection パラメーターを送信できます。この値は、Dashboard で定義された任意の接続に直接対応します。/authorize エンドポイントを呼び出して Hosted 版の Lock を使用している場合は、接続名を含む connection クエリ文字列パラメーターを渡せます。あるいは、埋め込み型 Lock を使用している場合は、auth0.show({connections: ['{yourConnection}']}); と記述するだけです。

  • connection の値を取得する実用的な方法はいくつかあります。その 1 つが vanity URL の使用です。たとえば、社内従業員は https://internal.yoursite.com を使用し、外部委託先は https://external.yoursite.com を使用します。

• メールアドレスのドメインを使用する: Lock は、認証リクエストを振り分ける方法としてメールアドレスのドメインを使用できます。Auth0 の Enterprise 接続は domains にマッピングできます。接続でこの設定を行うと、マッピングされたドメインのメールアドレスを入力した際に、パスワード入力欄は自動的に無効になります。1 つの接続に複数のドメインを関連付けることもできます。

このトピックの詳細については、複数の接続オプションから選択する を参照してください。

​

セッション管理

セッション管理では、通常、次の 3 つのセッションレイヤーを考慮する必要があります。

• アプリケーション セッション: 1 つ目は、アプリケーション内部のセッションです。ユーザーの認証に Auth0 を使用していても、そのユーザーがアプリケーションにログイン済みであることは、引き続きアプリケーション側で管理する必要があります。一般的な Web アプリケーションでは、これは cookie に情報を保存することで実現します。
• Auth0 セッション: 次に、Auth0 もセッションを保持し、ユーザー情報を cookie に保存します。次回ユーザーが Auth0 Lock 画面にリダイレクトされると、そのユーザーの情報は記憶されています。
• IDプロバイダー セッション: 最後のレイヤーは IDプロバイダー です。たとえば Facebook や Google です。ユーザーにこれらのプロバイダーでのサインインを許可していて、かつそのユーザーがすでにそのプロバイダーにサインインしている場合は、再度サインインを求められません。Auth0、ひいてはアプリケーションと情報を共有するための Permissions の許可のみを求められる場合があります。

そのため、Web アプリケーションを開発する際には、ユーザーがその Web アプリケーションにログインしていることを管理する必要があります。これを行うには、cookie ベースのセッションを使用してユーザーのサインイン状態を追跡し、ユーザー関連の情報やトークンも保存します。

​

ユーザーのローカル アプリケーション セッションの有効期間はどのように制御しますか? それを Auth0 から制御できますか?

Web アプリは、ユーザーのローカル アプリケーション セッションを完全に制御できます。通常、その方法は使用している Web スタック (たとえば ASP.NET) によって異なります。ただし、どの方法でも最終的には 1 つ以上の cookie を使ってセッションを制御します。開発者は、Auth0 から返される JWT の IDトークン の有効期限を使ってセッションの有効期間を制御することも、これを完全に無視することもできます。開発者の中には、IDトークン 自体をセッション状態に保存し、その有効期限が切れた時点でユーザーのセッションを終了させる人もいます。

トークンの有効期限をローカル セッションの有効期限の判定に使う理由は、ユーザー セッションの有効期間を Auth0 Dashboard から一元的に制御できるためです。

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

1. OIDC authentication flow を開始する: ユーザーのブラウザーが、OIDC フローを開始するためのリクエストを Auth0 に送信します。
2. SSO Cookie を設定する: Auth0 は、ユーザー情報を保存するための cookie を設定します。
3. code の交換を行い、IDトークン を返す: Auth0 は Web サーバーにリクエストを返して code を返します。Web サーバーはその code を IDトークン と交換します。
4. 認証 cookie を設定してレスポンスを送信する: Web サーバーはブラウザーにレスポンスを返し、ユーザーのセッション情報を保存するためのアプリケーション認証 cookie を設定します。
5. 以降のすべてのリクエストで認証 cookie が送信される: アプリケーション認証 cookie は、ユーザーが認証済みであることの証明として、以降のすべてのリクエストで送信されます。

​

Auth0 の SSO セッションはアプリケーションのセッションにどのような影響を与えますか?

Auth0 は独自のシングルサインオン セッションを管理します。アプリケーションは、独自のローカル セッションを維持する際に、その SSO セッションを尊重するか無視するかを選択できます。Lock ウィジェットには、Auth0 の SSO セッションが存在するかどうかを検出し、同じユーザーとして再度ログインするかどうかをユーザーに確認する特別な機能もあります。

その場合、実際の IdP に対して認証情報を再入力しなくてもサインインできます。ユーザーが改めて認証を行わなくても、アプリケーションは引き続き Auth0 との authentication flow を実行し、新しい IDトークン を取得します。これを使って、新しいローカル アプリケーション セッションを管理できます。

実装については ASP.NET Core を参照してください。

​

ユーザーのログアウト

ユーザーをログアウトさせる際は、前述した 3 つのセッションレイヤーを改めて考慮する必要があります。

• アプリケーションセッション: セッションをクリアして、Web アプリケーションからユーザーをログアウトさせる必要があります。
• Auth0 セッション: Auth0 からユーザーをログアウトさせる必要があります。そのためには、ユーザーを https://{yourDomain}/v2/logout にリダイレクトします。この URL にリダイレクトすると、Auth0 がそのユーザーに設定したすべての シングルサインオン cookie がクリアされます。
• IDプロバイダーのセッション: 一般的ではありませんが、Facebook や Google など、使用している IDプロバイダーからもユーザーを強制的にログアウトさせることができます。そのためには、ログアウト URL に federated クエリ文字列パラメーターを追加します: https://{yourDomain}/v2/logout?federated。

ログアウト後にユーザーをリダイレクトするには、遷移先 URL を値とする returnTo クエリ文字列パラメーターを追加します: https://{yourDomain}/v2/logout?returnTo=http://www.example.com。なお、returnTo URL は Allowed Logout URLs に追加しておく必要があります。実装方法の詳細については、ログアウト を参照してください。

ログアウトフロー (フェデレーテッドログアウトを除く) は次のとおりです。

1. ログアウトフローを開始: ログアウトフローはブラウザーから開始されます。たとえば、ユーザーが ログアウト リンクをクリックすると、Web サーバーにリクエストが送信されます。
2. ユーザーのローカルセッションをクリア: ユーザーのアプリケーションセッション / Cookie がクリアされます。
3. ブラウザーを Auth0 のログアウト先にリダイレクト: ユーザーのブラウザーは Auth0 のログアウト URL にリダイレクトされます。
4. SSO Cookie をクリア: Auth0 がユーザーの SSO Cookie をクリアします。
5. ログアウト後の URL にリダイレクト: Auth0 はリダイレクトレスポンスを返し、ユーザーのブラウザーを returnTo クエリ文字列パラメーターで指定された URL にリダイレクトします。

実装については ASP.NET Core を参照してください。

​

アクセス制御

認可とは、アプリケーション内でユーザーがどのような操作を実行できるかを判断するプロセスを指します。

認可は、Auth0 とは独立してアプリケーション内に直接実装することもできますし、利用可能な方法のいずれかを使用してユーザーの認可レベルを取得し、それらを IDトークン 内の認可クレームとして格納して、トークンの取得後にアプリケーション内でそれらのクレームを検証し、アクセスを制御することもできます。

Auth0 を使用する場合、ユーザーの認可クレームを取得して設定する方法はいくつかあります。

• Auth0 Authorization Extension を設定して使用する。
• Active Directory のグループを使用する。これらは、Active Directory のグループを Authorization Extension で定義したグループにマッピングすることで、Authorization Extension と組み合わせて使用できます。
• Rules を利用して、ユーザーのユーザープロファイルにメタデータを追加する。
• Rule 内から外部サービスを呼び出す。

このケースでは、会社ですでに Active Directory が設定されているため、Authorization Extension と Active Directory グループを組み合わせてアクセス制御を実施します。

Authorization extension

現時点で、Authorization Extension は主に大まかな粒度の認可を実施するために設計されています。たとえば、ユーザーのグループメンバーシップに基づいてアプリケーションへのアクセスを制御する場合です。今回の例ではこの方法を利用していますが、必ずしも細かな粒度のアクセス制御 (たとえば、ユーザーがアプリケーション内で特定の操作を実行できるかどうか) を目的として設計されているわけではありません。

すべてのユーザーは暗黙的に一般ユーザーになりますが、タイムシート管理者は Admin グループに割り当てられ、タイムシートを承認できるようになります。Authorization Extension では、既存のグループメンバーシップにグループをマッピングできます。

すべてのタイムシート管理者は、Active Directory 上の Timesheet Administrators グループに割り当てられ、これが Timesheet Application 内の Admin グループに自動的にマッピングされます。

Authorization Extension をインストールすると、バックグラウンドで Rule が作成され、次の処理が行われます。

1. ユーザーのグループメンバーシップを判定する。
2. ユーザーのグループメンバーシップ情報を app_metadata の一部として保存する。
3. ユーザーのグループメンバーシップを発行されるトークンに追加する。
4. ユーザーに現在のアプリケーションへのアクセスが許可されていることを確認する。

​

Authorization Extension をインストールする

Authorization Extension をインストールするには、Auth0 Dashboard の Extensions ビューに移動し、Auth0 Authorization Extension を選択してインストールします。

インストールが完了すると、Installed Extensions にアプリが表示されます。

初めて拡張機能を開くリンクをクリックすると、拡張機能が Auth0 アカウントにアクセスするための権限の付与を求められます。許可すると、Authorization Dashboard にリダイレクトされます。

Authorization Dashboard を開いたら、ナビゲーションメニューのグループに移動し、Admin という名前の新しいグループを作成します。

グループを追加したら、新しいグループをクリックしてグループ管理セクションに移動します。次に、Group Mappings タブを開き、新しいグループマッピングを追加します。これにより、Timesheet Admins グループ内のすべての Active Directory ユーザーが、先ほど作成した Admin グループにマッピングされます。

Save をクリックすると、新しいマッピングが一覧に表示されます。

このマッピングを設定すると、あとは Active Directory の Timesheet Admins グループのメンバーシップを管理するだけで、それらのユーザーはアプリケーション内の Admin グループに自動的にマッピングされます。

詳細については、Authorization Extension documentation を参照してください。

​

アプリケーションでPermissionsを適用する

Authorization Extension をインストールすると、特定のユーザーに関するすべての認可関連設定を含む authorization クレームを追加する Auth0 の Rule も作成されます。ユーザーのグループは、authorization クレーム内の groups というサブクレームとして追加され、そのユーザーが所属するすべてのグループがこのクレームに配列として格納されます。以下は、グループが含まれる IDトークン の JSON ペイロードの例です。

{
  "sub": "1234567890",
  "name": "John Doe",
  "authorization": {
    "groups": ["Admin"]
  }
}

そのため、アプリケーションでは、ユーザーの認証時に返されるIDトークンをデコードし、authorization クレームからそのユーザーが属するグループを抽出する必要があります。次に、それらのグループをほかのユーザー情報とともにユーザーのセッション内に保存し、後でそれらを参照して、グループメンバーシップに基づき、ユーザーが特定のアクションを実行するためのPermissionsを持っているかどうかを判断できます。

実装については、ASP.NET Coreを参照してください。