このシナリオでは、ExampleCo という架空の企業向けに Web アプリケーションを構築します。このアプリは、ExampleCo の従業員と契約社員が利用することを想定しています。従業員は既存の企業ディレクトリ (Active Directory) を使用し、契約社員は別個のユーザーストアで管理されます。
- Auth0 は、認証と認可のために OAuth 2.0 や などのオープン標準をサポートしています (どのプロトコルを使用するか を参照)
- OIDC は複数の認可フローをサポートしており、Web アプリケーションに最も適しているのは Authorization Code Flow です (認証フロー を参照)
- アプリケーションは Auth0 でアプリケーションとして設定されます (Application を参照)
- IDプロバイダーは Auth0 で接続として設定されます (Connections を参照)
- Auth0 は、ユーザーがアプリケーションにログインするための Lock ウィジェットを提供しています (User Login を参照)
- Web アプリケーションは、ユーザーがログインしている状態を追跡するためにセッション状態を管理する必要があります。これに加えて、Auth0 と IDプロバイダーもセッション情報を管理します (Session Management を参照)
- 一方、ユーザーをログアウトする場合も、3 層のセッション管理が関係します (User Logout を参照)
- アクセス制御は Auth0 Authorization Extension で管理できます (Access Control を参照)
ここでいう Regular Web App とは、主にサーバー側でページの GET、POST、および状態維持のための cookie を使用するアプリを指します。これは、API を呼び出すクライアント側の JavaScript コードに大きく依存する Web SPA (Single-Page App) とは対照的です。
認証と認可
ExampleCo は各ユーザーを認証し、認可したいと考えています。認証は本人確認に関するもので、ユーザーが本人であることを検証します。認可は、ユーザーがどのリソースにアクセスできるか、またそのリソースに対して何を実行できるかを判断するものです。
-
User ロールを持つユーザーは、日付、アプリケーション、勤務時間を指定してタイムシートのエントリを追加できます。Admin ロールにもこの権限があります。
-
User ロールを持つユーザーは、自分のタイムシートエントリにのみアクセスできる必要があります。
-
Admin ロールを持つユーザーは、さらに次のことができます。
- 他のユーザーのタイムシートエントリを承認または却下する。
- アプリケーションのドロップダウンリストの値を編集する (追加、編集、削除) 。
各ユーザーは、週末までに自分のタイムシートを記入する必要があります。タイムシートは毎日登録することも、1 週間分をまとめて追加することもできます。タイムシートは Admin による確認と承認が必要です。却下されたエントリは各従業員が更新し、承認のために再提出する必要があります。
この会社では全従業員に Active Directory を使用しており、従業員は Active Directory の認証情報を使って Timesheet アプリケーションにサインインします。外部委託先の契約者は username とパスワードでサインインできます。契約者は ExampleCo の社内ディレクトリには含まれていません。
ExampleCo はユーザーのログイン時の負担を最小限に抑えたい一方で、操作に応じたセキュリティレベルは維持したいと考えています。たとえば、タイムシートエントリの送信は、承認よりもリスクの低い操作です。しかし、承認済みのタイムシートは顧客への請求に使用されるため、セキュリティは重要な要件です。認証戦略は、会社の成長に合わせて柔軟に対応できる必要があります。たとえば、Admin に対して のような追加の認証要件を簡単に加えられる必要があります。
このソリューションは、会社のオフィスに出社している従業員にも、リモートで勤務している従業員にも、VPN 接続の運用負荷なしで利用できる必要があります。そのため、このアプリは Heroku や Microsoft Azure などのクラウドプロバイダー上にデプロイする必要があります。
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム