- 認証（Authentication） ：プリンシパル（ユーザーまたはアプリケーション）が自己申告している通りの人物または存在かどうかを判断するプロセス。
- 認可（Authorization） ：プリンシパルに基づいて、許可されているのは何か、付与されているアクセス許可は何か、および/またはコンテキストに即した一連のアクセス条件を判断するプロセス。
- 同意（Consent） ：ユーザー（リソース所有者）が、自身の代わりに実行することを許可するためにアプリケーションに付与したアクセス許可。これは通常、委任された認可の要件になります。ユーザーは、異なるシステムにあるユーザーのデータへのアクセス許可をクライアントに付与する必要があります。
- ポリシー適用（Policy Enforcement） ：アプリケーションまたはAPIのポリシーを適用する行為で、ユーザーの認証情報および/または認可情報に基づいてアクセスを拒否または許可します。
- 1つめのカテゴリは、アプリケーションまたはAPI全体へのアクセスが許可または拒否される場合です。通常、これを適用するために必要なデータと適用プロセスの両方が、認可サーバーのコンテキストで定義されます。たとえば、ユーザーに紐づけられた
app_metadataと、Auth0テナントで定義されているRuleを使用する、というようにです。 - 2つめのカテゴリは、アプリケーションまたはAPIの機能性の、特定のサブセットへのアクセスが許可または拒否される場合です。これを適用するために必要なデータは通常、認可サーバーに保管されます。たとえば、Auth0テナントにあるユーザーの
app_metadataを使用して、アプリケーションまたはAPI自体で実行される適用プロセスによって行います。このシナリオでは、データは通常、idまたはaccessトークンで1つ以上のカスタムクレームとして伝達されます。 - 3つめのカテゴリは、アプリケーションまたはAPIのコンテキスト内でプリンシパル（サブジェクト）が操作できるものに応じてアクセスが許可または拒否される場合です。通常、これを適用するために必要なデータと適用プロセスの両方が、アプリケーションまたはAPIのコンテキストで定義されます。このシナリオでは、
idまたはaccessトークンで1つ以上のカスタムクレームとして伝えられるデータが、Auth0以外の外部ソースからのデータを伴って、または伴わずに利用されます。
- アプリケーションまたはAPI全体へのアクセスを拒否すべきシナリオはあるか？
- サードパーティアプリケーションがアクセスできるAPIを提供するか？
- 自社（ファーストパーティ）のアプリケーションもAPIにアクセスするか？
- アプリケーションがサードパーティAPIを呼び出すか？
- アプリケーションおよび/またはAPIはユーザークレームに基づいてアクセス制御を適用すべきか？
- アクセストークンまたはIDトークンが紐づけられているOrganizationを知る必要がある場合はどうするか？
UnauthorizedErrorを返すRuleを作成する必要があります。たとえば、ユーザーが誤った時間にアプリケーションまたはAPIへのアクセスを試みたとき（こちらの例を参照）や、ユーザーのapp_metadataに適切なクレームが含まれていない場合です。OpenID Connect（OIDC）を使ったアプリケーションの場合は、これによって、アクセス認可に使用されるIDトークンの割り当てが妨げられます。同様に、APIの場合、この例で説明されているように、OAuth2アクセストークン（APIの呼び出しに使用）の割り当てが妨げられる可能性があります。
Auth0は、アプリケーションが制限を適用できるように、必要な情報を提供することもできます。アプリケーションレベルの統合では、Auth0を使用すると、カスタムクレームをIDトークンに追加できます。アプリケーションはこれを検証し、ポリシー適用に使用できます。この場合、アプリケーションが適用を判断するのに必要な情報を決める必要があります。アプリケーションではなくAPIで判断する必要がある場合は、おそらくIDトークンの代わりにアクセストークンを使用する必要があります。詳細については、このまま読み進めてください。
IDトークンやアクセストークンにどのデータを含めるかを決めるとき、特にURLでトークンを渡す場合は、トークンサイズを考慮してください。また、URLでトークンを渡さない場合でも、機密のPII（個人を特定できる情報）をさらしてしまう可能性について考える必要があります。IDトークンの漏洩は一般的にセキュリティ上の問題にはなりませんが、トークン情報は暗号化されないため、トークンに含めるデータによってはプライバシー上の問題が生じます。
ベストプラクティス
カスタムクレームまたはスコープを通じて許可を使用するべきかどうかを決定する際に、スコープの性質と目的を理解する必要があります。読みやすく、トピックについて理解を深めるためのおすすめ［ブログ記事］（https://auth0.com/blog/on-the-nature-of-oauth2-scopes/）をご覧ください。アプリケーション統合
このシナリオでは、Auth0テナントが、アプリケーションへのアクセスが認可されていることを示す指標としてトークンを提供します。対顧客アプリケーションで一般的に最も利用されている業界標準プロトコル、OpenID Connect（OIDC）を活用するアプリケーションの場合、これはJWTと呼ばれるIDトークンになります。IDトークンのクレーム
Auth0ではRuleの拡張性を利用して、たとえばユーザーのメタデータの内容に基づき、簡単にIDトークンにカスタムクレームを追加することができます。次に、アプリケーションは必要なクレームのIDトークンを検証し、必要に応じて特定の機能性へのアクセスを許可または拒否することができます。Ruleを利用したカスタムクレームの追加プロセスは合理化されているものの、Ruleエンジンには柔軟性があってカスタムコードを書き込むことができるため、意図しない影響を与えることもあるので注意してください。この拡張性機能を使用する際は、常に、ルールのベストプラクティスのガイダンスに従って作業することが重要です。ベストプラクティス
カスタムクレームの追加を検討している場合は、ユーザーのapp_metadataの一部としてクレームに含める必要のあるアクセス制御データを保管することをお勧めします。まず第一に、これによりデータを取得するために外部のAPIを呼び出す必要がなくなります。外部APIの呼び出しはログインシーケンスのパフォーマンスと拡張性に悪影響を与える可能性があります。第二に、app_metadataはユーザーによって直接変更「できない」ため、ユーザーが自身のメタデータを変更してアクセス制御の制限を回避することはできません。「メタデータのベストプラクティス」のガイダンスも参考にしてください。IDトークンのスコープ
OIDCスコープは、通常、認証中にアプリケーションがユーザーの情報にアクセスするための同意を取得するために使用されます。事前定義された各スコープは、定義された、OIDC仕様で説明されている標準クレームのセットを返します。アプリケーションが要求するスコープは、そのアプリケーションでどのユーザー属性が必要かによります。要求されたスコープがユーザーによって認可されると、クレームはIDトークンで返され、/userinfoエンドポイント経由でも利用できるようになります。API統合
このシナリオでは、Auth0テナントは、一般的にJWTと呼ばれるOAuth2アクセストークンを提供できます。APIはこれを使用して、特定の当事者へのアクセスを制限できます。加えて、Auth0は、概念的にファーストパーティとサードパーティのアプリケーションと呼ばれる両方をサポートします。 Auth0テナントは認可サーバーとして機能し、ユーザー（リソース所有者）の同意を得て、一般的にJWTと呼ばれるアクセストークンをアプリケーション（クライアント）に提供するために使用できます。これにより、リソース所有者の代理として、リソースサーバーにホストされている保護されたリソースにアクセスできるようになります。発行されたアクセストークンは通常、APIに送信されるHTTP認可ヘッダーでBearerトークンとして渡されます。 単一のAPIであっても、論理的に関連するマイクロサービスAPI一式であっても、Auth0が提供するアクセストークンを活用してサービスへのアクセスを保護できます。これをAuth0 Dashboardで、またはAuth0 Management APIを通じてセットアップするのは比較的簡単ですが、さまざまなアプリケーションのシナリオとAPIのレイアウトを確認して、システムに最適なアーキテクチャを判断することが重要です。OAuth2のアクセストークンは、主に公開APIのセキュリティ保護で使うために設計されています。アクセストークンは、JWTで表記されると自己完結型エンティティになるため、サードパーティのAPIを呼び出すことなく検証できます。使用しているAPIがアプリケーションの一部（アプリケーションによってのみ呼び出される）である、またはファイアウォールの内側にあるなど、これに該当しない場合には、既存のクッキーベースなどのワークフローで十分に保護されており、トークンで保護することは過剰かもしれません。
アプリケーションをファーストパーティとして構成し、その後、ファーストパーティのクライアントが同意を無視できるようにAPIを構成することはできますが、
localhostを使用している場合、Auth0はアプリケーションが本当にファーストパーティアプリかどうかを確認できないため、ユーザーはいずれにせよ同意を求められます。この制約を回避するには、開発時にローカルマシンでテストするときに、偽のローカルホスト名を作成して使用します。アクセストークンのクレーム
IDトークンの場合と同様に、Auth0のRule拡張性を利用して、カスタムクレームをアクセストークンに追加できます。その後、APIは必要なクレームのアクセストークンを検証し、必要に応じて特定の機能性へのアクセスを許可または拒否することができます。ベストプラクティス
カスタムクレームの追加を検討している場合は、ユーザーのapp_metadataの一部としてクレームに含める必要のあるアクセス制御データを保管することをお勧めします。まず第一に、これによりデータを取得するために外部のAPIを呼び出す必要がなくなります。外部APIの呼び出しはパフォーマンスと拡張性に悪影響を与える可能性があります。第二に、app_metadataはユーザーによって直接変更「できない」ため、ユーザーが自身のメタデータを変更してアクセス制御の制限を回避することはできません。「メタデータのベストプラクティス」のガイダンスも参考にしてください。アクセストークンのスコープ
OAuth2スコープは通常、APIがユーザーに代わって実行できるアクションを決定できるメカニズムとして使用されます。スコープはAPIごとに追加でき、で、またはAuth0 を通じて特定のアクセス許可を定義します。また、スコープはAuth0の拡張性を介して操作することもできます（この例のように、Rule経由など）。アプリケーションがAPIにアクセスするために要求するスコープは、アプリケーションが使用するためにユーザーがアクセス許可を与える必要がある機能性に依存する必要があります。要求されたスコープが認可されると、アクセストークンで返され、そのAPIによって検証できるようになります。良い例が、ログインにソーシャルプロバイダーを使用しているアプリケーションにログインする場面です。ソーシャルプロバイダーのAPIは、ユーザーが自分に代わってアプリケーションにアイテムを投稿させるかどうかをアプリケーションが指定することを求めます。これによって、ユーザーはこの要求を許可または拒否できます。この例は、ユーザーがアプリケーションにアクセス許可を委任する方法を示しています。ユーザーロールに基づいてアクセスを制限するAPIとは異なり、別の方法で処理する必要があります。ベストプラクティス
Auth0の拡張性を通じて完全にアクセストークンスコープを操作できる能力を持っているとしても、セキュリティのベストプラクティスとして、消去するのは認可されていないスコープのみにし、要求されていないスコープの追加は避けるべきです。Fine-grained Authorization（FGA）
Fine Grained Authorizationを使用すると、以下の事項に基づいて特定のリソースまたはオブジェクトへのアクセスを個々のユーザーに付与できます。editorやeditorなど、Organization内でのユーザーの役割- ユーザーまたはオブジェクトの属性（ユーザーの
managerやオブジェクトのmarketingなど） - ユーザーとオブジェクト間の関係（親フォルダーに対して表示アクセス権を持つユーザーは、その子フォルダーに対する表示アクセス権も持つなど）
Role Based Access Control（RBAC）
Auth0では、すぐに使えるRole Based Access Control（RBAC）がサポートされます。RBACとは、Organization内でのロールに基づいてユーザーにアクセス許可を割り当てることを指します。エラーが発生しにくく、管理しやすい方法なので、アクセス制御がシンプルになります。 RBACのコア機能は、多くの複数Organizationのシナリオで使用できます。セットアップでRBACのニーズをサポートできるようにする方法の詳細は、「アクセストークンのOrganizationデータ」を参照してください。マシンツーマシン（M2M）アプリケーション
APIを呼び出すために、ユーザー対話型セッションのないアプリケーションでアクセストークンを取得する必要があるシナリオは少なくありません。このようなシナリオでは、ユーザーではなくクライアントを認証しなければならず、 2では、これを簡単に達成できるクライアント資格情報付与タイプを提供しています。これが必要な一般的な例：- APIと通信する必要があるcronジョブまたはその他のサービス（たとえば、毎日レポートを生成して管理者にメールで送信する必要がある場合）。
- 特権アクセスをサポートする個別のAPI（たとえば、APIがユーザーの目に直接触れることがなく、バックエンドでのみ稼働する場合）。
- 一部のAPIレイヤーがユーザーの関与なしに、またはユーザートークンの有効期限が切れた後に、他のAPIレイヤーと通信する必要がある、特定のマイクロサービスアーキテクチャ。
- ユーザーが認証される前に（Auth0テナントのルールまたはカスタムDBスクリプトから）呼び出される必要がある、権限のあるAPI
ベストプラクティス
今までは特別な「サービスアカウント」を作成することでこのようなケースに対応してきました。つまり、非対話的なユースケースに対応するサービスのために構成されたユーザー名とパスワードを持つユーザーのことです。さまざまな理由から、このアプローチは現在は推奨されていません。最新のベストプラクティスは、OAuth 2.0クライアント資格情報付与を使用することです。アクセストークンのOrganizationデータ
複数Organizationのアプリケーションをサポートするシステム内に、アプリケーションとは別にAPIがある場合は、トークンが生成されたOrganizationのみに操作を制限することが重要です。これには、アクセストークンがどのOrganizationに対して発行されたかをAPIに伝えるための何らかの情報がアクセストークンに含まれている必要があります。次の簡単な質問に対する答えに応じて、どのような方法で行うかを決めることができます。- このOrganizationのエンドユーザーが複数のOrganizationに所属する可能性があるか、それとも各エンドユーザーが特定のOrganizationにしか所属せず隔離されるか？
- APIへのマシンツーマシン（M2M）アクセスを許可するか？
- APIへのマシンツーマシン（M2M）アクセスを許可する場合は、（すべてのOrganizationではない）複数のOrganizationにアクセスするための単一のクライアントIDとシークレットを必要とする開発者がいるか？
- 同意を必要とするサードパーティアプリの作成を許可するか？
- まず、カスタムパラメーターを作成しなくても、オーディエンスをファーストクラスパラメーターとしてAuth0に渡すことができます。この利点は、Auth0がオーディエンスの存在を強制することを助けてくれ、それをルールに渡すことです。また、発行されたリフレッシュトークンが、元々の発行対象である特定のオーディエンスに対してのみ機能することも保証されます。
- これにより、特に変更する手間なく、クライアントの許可を特定のOrganizationのみにすぐに制限できます。これ以外の方法では、より複雑なクライアント資格情報フックを作成し、他の場所から制限の取得を試みて、クライアント資格情報呼び出しにアクセストークンの発行先Organizationを指示するための、より複雑で潜在的に面倒な方法も必要になります。
- これにより、Auth0でコアRBAC機能を使用することも可能になり、複数のOrganizationにアクセスできるエンドユーザーが各Organizationに対して潜在的に異なるロールを持つことができるようになります。