- 認証: プリンシパル (ユーザーまたはアプリケーション) が、名乗っている本人またはその主体であるかどうかを判断するプロセス。
- 認可: プリンシパル、付与されている権限、そして/または状況に応じた具体的なアクセス条件のセットに基づいて、何が許可されるかを判断するプロセス。
- 同意: ユーザー () が、アプリケーションに対して自身に代わって何を行うことを許可したかを指します。これは一般に委任された認可の要件です。ユーザーは、別のシステムにある自分のデータに Client がアクセスすることを許可する必要があります。
- ポリシー適用: アプリケーションまたは API のポリシーを適用し、ユーザーの認証情報および/または認可情報に基づいてアクセスを拒否または許可すること。
- 1 つ目のカテゴリは、アプリケーションまたは API 全体に対してアクセスを許可または拒否するものです。これを適用するために必要なデータと適用プロセスは、通常、認可サーバーのコンテキストで定義されます。たとえば、ユーザーに関連付けられた
app_metadataと、Auth0 テナントで定義された Action を使用する方法があります。 - 2 つ目のカテゴリは、アプリケーションまたは API の機能の特定の一部に対してアクセスを許可または拒否するものです。これを適用するために必要なデータは、通常、認可サーバーに保存されます。たとえば、Auth0 テナント内のユーザーの
app_metadataを使用し、適用プロセスはアプリケーションまたは API 自体で実行されます。このシナリオでは、データは通常、idまたはaccessトークン内の 1 つ以上のカスタムクレームとして伝達されます。 - 3 つ目のカテゴリは、アプリケーションまたは API のコンテキストの中で、プリンシパル (サブジェクト) が何を操作できるかに応じてアクセスを許可または拒否するものです。これを適用するために必要なデータと適用プロセスは、通常、アプリケーションまたは API のコンテキストで定義されます。このシナリオでは、
idまたはaccessトークン内の 1 つ以上のカスタムクレームとして伝達されるデータは、Auth0 以外の外部ソースのデータと組み合わせて、あるいは組み合わせずに利用されることがあります。
- アプリケーションまたは API 全体へのアクセスを拒否すべきシナリオはありますか？
- サードパーティアプリケーションからアクセスできる API を提供する予定はありますか？
- 自社の (ファーストパーティ) アプリケーションからも API にアクセスしますか？
- アプリケーションからサードパーティ API を呼び出しますか？
- アプリケーションおよび/または API で、ユーザーのクレームに基づくアクセス制御を強制適用する必要がありますか？
app_metadata に必要な が含まれていない場合に、api.access.deny() を使ってアクセスを拒否する Action を作成したいことがあります。OpenID Connect (OIDC) を使用するアプリケーションでは、これによりアクセス認可に使われる ID Token の発行を防ぐことができます。同様に API の場合も、API 呼び出し時に使用される OAuth2 の Access Token の発行を、この例で説明されているように防ぐことができます。
Auth0 は、アプリケーション側で制限を適用するために必要な情報を提供することもできます。アプリケーションレベルの統合では、Auth0 で にカスタムクレームを追加でき、アプリケーションはそれを検証したうえで、ポリシーの適用に利用できます。この場合は、アプリケーションが適用判断を行うためにどの情報が必要かを決める必要があります。アプリケーション内ではなく API 側で判断する必要がある場合は、ID token ではなく を使用することになる可能性が高いです。詳しくはこのまま読み進めてください。
API レベルの統合では、Auth0 は Access Token のコンテキスト内で、カスタムクレームとスコープの再設定の両方をサポートしています。ここでも、API がアクセス判断を行うために必要な情報が何かを決める必要があり、API は Access Token の内容を検証してそれを適用する必要があります。
カスタムクレームまたはスコープを通じて権限を使うかどうかを判断する際は、スコープの性質と目的をきちんと理解しておく必要があります。この点については、読みやすく、理解を深めるのに役立つブログ記事があります。
アプリケーション統合
このシナリオでは、Auth0テナントが、アプリケーションへの認可されたアクセスを示すトークンを提供します。OpenID Connect (OIDC) を利用するアプリケーション、つまり顧客向けアプリケーションで一般的に最も広く使われている業界標準のプロトコルの場合、これは JWT 形式の ID Token になります。ID Token クレーム
Action の拡張機能を利用すると、Auth0 では、たとえばユーザーの Metadata の内容に基づいて、ID Token にカスタムクレームを追加することが簡単にできます。これにより、アプリケーションは ID Token に必要なクレームが含まれているかを検証し、必要に応じて特定の機能へのアクセスを許可または拒否できます。Action を使ったカスタムクレームの追加は簡単ですが、Action ランタイムは柔軟性が高いため、悪影響を及ぼす可能性のあるカスタムコードも記述できる点に注意してください。カスタムクレームの追加を検討している場合は、クレームに含める必要のあるアクセス制御データを、ユーザーの
app_metadata の一部として保存することをお勧めします。まず、これによりデータ取得のために外部 API を呼び出す必要がなくなり、ログイン処理のパフォーマンスやスケーラビリティへの悪影響を抑えられます。次に、app_metadata はユーザーが変更できないため、ユーザーが自分自身の を変更してアクセス制御の制限を直接回避することはできません。あわせて、メタデータ のベストプラクティス に関するガイダンスもご確認ください。ID Token スコープ
OIDC Scopes は通常、認証時にユーザーの詳細情報への認可されたアクセスについて同意を得るためにアプリケーションで使用されます。事前定義された各スコープは、定義されている標準クレームのセットを返します。その内容は OIDC specification に記載されているとおりです。アプリケーションが要求するスコープは、そのアプリケーションが必要とするユーザー属性によって異なります。ユーザーが要求されたスコープを認可すると、クレームは ID Token で返され、 /userinfo エンドポイントからも利用できます。API 連携
このシナリオでは、Auth0 テナント は OAuth2 の Access Token (通常は JWT 形式) を発行でき、API はこれを使って特定の主体にのみアクセスを許可できます。さらに Auth0 は、概念的に First-Party and Third-Party Applications の両方をサポートしています。 認可サーバーとして機能する Auth0 テナント は、ユーザー (リソースオーナー) の同意を得たうえで、アプリケーション (クライアント) に Access Token (通常は JWT 形式) を発行できます。これにより、そのアプリケーションはリソースオーナーに代わって、 でホストされている保護されたリソースにアクセスできます。発行された Access Token は通常、API に送信する HTTP Authorization ヘッダー内で Bearer トークンとして渡されます。 API が 1 つだけの場合でも、論理的に関連する microservice APIs 群がある場合でも、Auth0 が提供する Access Token を利用してサービスへのアクセスを保護できます。Auth0 Dashboard または Auth0 Management API から比較的簡単に設定できますが、システムに最適なアーキテクチャを判断するには、さまざまなアプリケーションシナリオや API 構成を確認することが重要です。OAuth2 Access Token は主に、公開 API を保護する用途を想定して設計されています。JWT 形式の Access Token は自己完結型であるため、追加でサードパーティ API を呼び出さなくても検証できます。API がこのカテゴリに当てはまらない、つまりアプリケーション自体の一部であってそのアプリケーションからしか呼び出されない場合や、ファイアウォールの内側に配置されている場合は、トークンで保護するのは過剰かもしれず、既存の Cookie ベースなどのワークフローで十分なこともあります。
Access Token のクレーム
ID Token と同様に、Auth0 Action の拡張機能を使用して、Access Token にカスタムクレームを追加できます。追加後は、API で Access Token に必要なクレームが含まれているかを検証し、必要に応じて特定の機能へのアクセスを許可または拒否できます。カスタムクレームの追加を検討している場合は、クレームに含める必要があるアクセス制御データを、ユーザーの
app_metadata に保存することをお勧めします。1 つ目の理由は、データ取得のために外部 API を呼び出す必要がなくなり、パフォーマンスやスケーラビリティへの悪影響を避けられるためです。2 つ目に、app_metadata はユーザーが変更できません。そのため、ユーザーが自分でメタデータを書き換えてアクセス制御の制限を直接回避することはできません。メタデータ のベストプラクティス に関するガイダンスもぜひご確認ください。Access Token のスコープ
OAuth2 Scopes は通常、API がユーザーに代わってどの を実行できるかを判断するための仕組みとして使用されます。スコープは API ごとに追加でき、 または Auth0 で 特定のアクセス権限を定義 できます。スコープは、Auth0 の拡張機能 (たとえば、この例のように Action 経由) で操作することもできます。アプリケーションが API にアクセスするために要求するスコープは、アプリケーションが利用する機能のうち、ユーザーの許可が必要なものに応じて決めるべきです。要求されたスコープが承認されると、それらは Access Token に含まれて返され、後で その API によって検証 できます。これをよく示す例として、ソーシャルプロバイダーを使ってログインするアプリケーションにログインする場合があります。ソーシャルプロバイダーの API では、アプリケーションがユーザーに代わって投稿を行うことをユーザーが許可するかどうかを、アプリケーション側で指定する必要があります。これにより、ユーザーはこの要求を承諾または拒否できます。この例が示しているのは、ユーザーがアプリケーションに権限を委譲しているということです。これは、API がユーザーの に基づいてアクセスを制限するのとは異なるため、別の方法で扱う必要があります。 スコープはユーザーのアクセス権限を適用する手段としてよく使われますが、このような使い方をすると 扱いが難しくなる ことがあります。そのため、スコープは本来の目的 (つまり、アプリケーションへの権限の委譲) に使い、ロールベースやその他のアクセス制御のシナリオでは カスタムクレーム を使用することをお勧めします。きめ細かな認可 (FGA)
きめ細かな認可を使用すると、次の条件に基づいて、特定のリソースまたはオブジェクトへのアクセス権を個々のユーザーに付与できます。editorやadminなど、組織内でのユーザーの役割- ユーザーの
managerやオブジェクトのmarketingなど、ユーザーまたはオブジェクトの属性 - ユーザーとオブジェクトの関係。たとえば、親フォルダーへの閲覧権限を持つユーザーは、子フォルダーへの閲覧権限も持ちます
ロールベースのアクセス制御 (RBAC)
Auth0 は、ロールベースのアクセス制御 (RBAC) を標準でサポートしています。RBAC とは、組織内でのユーザーの役割に応じてユーザーに permissions を割り当てることで、より管理しやすくミスも起こりにくい方法を提供し、アクセス制御を簡素化するものです。マシン間 (M2M) 認可
ユーザーとの対話セッションを伴わないアプリケーションが、API を呼び出すために Access Token を取得する必要があるケースは数多くあります。こうしたケースでは、ユーザーではなくクライアントを認証する必要があり、 2 では、これを簡単に実現できるように client credentials グラントタイプが提供されています。これが必要になる代表的な例として、次のようなものがあります。- API と通信する必要がある cron ジョブやその他のサービス (例: 日次レポートを生成して管理者にメールで送信する必要がある場合) 。
- 特権アクセスをサポートする別の API (例: その API はユーザーに直接公開されず、バックエンドからのみ利用される場合) 。
- 一部のマイクロサービス アーキテクチャで、ユーザーが関与しないまま、またはユーザートークンの有効期限が切れた後に、ある API レイヤーが別の API レイヤーと通信する必要がある場合。
- ユーザーが認証される前に呼び出す必要がある特権 API (つまり、Auth0 テナント内のアクションやカスタム DB スクリプトから呼び出す場合)
従来、こうしたケースに対応するために、特別な「サービスアカウント」を作成するのが一般的でした。これは、非対話型のユースケースをサポートするサービス向けに設定された、ユーザー名とパスワードを持つユーザーです。しかし、この方法は多くの理由から現在では推奨されておらず、このような状況での現在のベストプラクティスは、OAuth 2.0 Client Credentials Grant を使用することです。