要点
- Auth0 は、認証と認可のために OAuth 2.0 や などのオープン標準をサポートしています (使用するプロトコルを参照)
- OIDC は複数の認可フローをサポートしており、Webアプリケーションに最も適しているのは認可コードフローです (認証フローを参照)
- アプリケーションは、Auth0 でアプリケーションとして設定されます (アプリケーションを参照)
- IDプロバイダーは、Auth0 で接続として設定されます (接続を参照)
- Auth0 は、ユーザーがアプリケーションにログインするための Lock ウィジェットを提供しています (ユーザーログインを参照)
- Webアプリケーションでは、ユーザーがログインしている状態を維持するためにセッション状態を管理する必要があります。これに加えて、Auth0 と IDプロバイダーもセッション情報を管理します (セッション管理を参照)
- 逆に、ユーザーをログアウトする場合も、3 層のセッション管理が関係します (ユーザーログアウトを参照)
- アクセス制御は Auth0 Authorization Extension で管理できます (アクセス制御を参照)
ここでいう Regular Web App とは、主にサーバー側の処理とページの
GET、POST、および状態維持のための Cookie を使用するアプリを指します。これは、API を呼び出すクライアント側の JavaScript コードに大きく依存する Web SPA (シングルページアプリ) とは対照的です。前提
ExampleCo はコンサルティング系のスタートアップ企業です。現在、従業員は約100名おり、いくつかの業務を外部の契約業者に委託しています。従業員の大半は本社オフィスで勤務していますが、一部のチームはリモートで働いています。さらに、一部の従業員は顧客先への出張が多く、モバイル端末から業務を行っています。 従業員と外部の契約業者は全員、毎週スプレッドシートでタイムシートを記入する必要があります。現在の仕組みは非効率なため、会社はより優れた自動化されたソリューションへ移行する必要があると判断しました。 会社は利用可能なタイムシート用アプリケーションをいくつか評価した結果、現時点では非常にシンプルなアプリケーションを求めていることから、自社で独自のソリューションを構築するほうが費用対効果が高いと結論づけました。このアプリは ASP.NET Core を使って構築されます。開発者はすでにこの技術に習熟しており、1週間ほどでアプリを用意できるからです。目標と要件
ExampleCo は新しいソリューションをすばやくローンチしたいため、まずはシンプルに始めて、従業員からのフィードバックを集めながら段階的に機能を拡張していくことにしました。 このアプリケーションは、ログイン済みのユーザーのみが利用できる必要があります。各ユーザーにはロールがあり、そのロールに応じて特定の操作を行い、特定のデータを閲覧できるようにする必要があります。認証と認可の違い
ExampleCo は各ユーザーを認証し、認可したいと考えています。認証は本人確認に関するもので、ユーザーが名乗っている本人であることを検証します。認可は、ユーザーがどのリソースにアクセスできるか、またそのリソースに対して何を許可されるかを判断することです。- User ロールを持つユーザーは、日付、アプリケーション、勤務時間を指定してタイムシート エントリを追加できます。Admin ロールにも同じ権限があります。
- User ロールを持つユーザーは、自分自身のタイムシート エントリにのみアクセスできる必要があります。
-
Admin ロールを持つユーザーは、さらに次のことができます。
- 他のユーザーのタイムシート エントリを承認または却下する。
- アプリケーションのドロップダウンリストの値を編集する (追加、編集、削除) 。
