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