本記事は「A Practical Guide to Scopes, Roles, Permissions and Client Grants」を翻訳した記事です。
ユーザーデータを扱うすべてのアプリケーションは認可の決定を下しますが、多くは誤った決定を下しています。アクセス制御の不備は2021年以来OWASPトップ10の首位を占めており、Webアプリケーションにおける最大のセキュリティ脅威であり続けています。
「誰であるか」と「何ができるか」のギャップで侵害が発生します。両者を正確に定義します。
- 認証: ログインプロンプト、パスワードチェック、多要素認証など、身元を確認するプロセスです。「誰であるか」に答えます。
- 認可: 身元が確立された後にポリシーを適用するプロセスです。「何を許可されているか」に答えます。
認可がアプリケーションの第一の防衛線である理由
堅牢な認可戦略はアプリケーションの最も重要な内部保護手段です。背後にある基本原則はシンプルかつ強力であり、最小特権の原則と呼ばれます。
ユーザーやアプリケーションは正当な機能を実行するために必要な最小限の権限セットのみを受け取るべきであり、それ以上は不要です。正しく実装することで攻撃対象領域を減らし、認可に関連する技術的負債を排除します。
Auth0で正しく実装するには、4つのコアコンポーネントを理解する必要があります。
Auth0認可のコアコンポーネント
各コンポーネントは誰がどのコンテキストで何を行えるかを決定する上で、明確な役割を果たします。
- ロール: ロールはユーザーに割り当てられる権限の名前付きコレクションです。多数の権限を直接割り当てる代わりに、ロール(在庫管理者など)を作成して関連する権限を割り当て、ユーザーに割り当てます。
- 権限: 権限はAPIで定義されるきめ細かな操作です(例:read:orders)。権限は認可の最も基本的な単位であり、Auth0ダッシュボードのAPI設定で定義されます。
- クライアントグラント: クライアントグラントはアプリケーション自体が要求を認可される権限を定義します。クライアントグラントはアプリケーション自体に直接権限を割り当てます。2つの目的を果たします。クライアントクレデンシャルフローを介したMachine-to-Machine(M2M)通信の保護と、ユーザー向けアプリケーションの権限の上限としての機能です。誰がログインするかに関係なく最小特権を強制します。
- スコープ: スコープは二重の役割を果たします。認可フロー中にアプリケーションが要求する権限であり、Auth0が設定を評価した後にアクセストークンで実際に付与される権限でもあります。要求と付与のギャップにセキュリティポリシーが存在します。権限、特権、スコープの違いに関する詳細は、以前のブログPermissions, Privileges, and Scopesを確認ください。
トークン権限を制御する2つの設定
上記の4つのコンポーネントは定義する対象です。以下の2つの設定はアクセストークンを発行する際にAuth0がコンポーネントをどのように組み合わせるかを制御します。
- RBAC(ロールベースアクセス制御の有効化): 有効にすると、Auth0は認可フロー中にユーザーに割り当てられたロールと関連する権限を評価します。無効にすると、ユーザーレベルの権限はトークンに考慮されず、ユーザーのロールは事実上無視されます。
Auth0ダッシュボードのAPIs > [対象のAPI] > Settings > RBAC Settings
RBAC設定までスクロールし、Enable RBACを切り替えます。
Application Access Policy(ユーザーアクセス用): アプリケーションのクライアントグラントが権限の上限として機能するかどうかを決定します。
- Allow: アプリケーションは制限なしで信頼されます。トークンスコープはユーザーの権限のみから派生します(有効にするにはRBACを有効にする必要があります)。
- Allow via Client Grant: アプリケーションのクライアントグラントが厳格な境界になります。ユーザーのロールが認可するものに関係なく、アプリケーションに明示的に付与された権限のみがトークンに表示されます。
- Deny: アプリケーションは信頼されず、結果としてAPI権限へのアクセスが制限されます。
Auth0ダッシュボードのAPIs > [対象のAPI] > Application Access
APIの「Edit」ボタンをクリックし、「Allow via client-grant」ポリシーの特定の権限を付与します。
2つの設定の組み合わせにより、根本的に異なる3つの認可モデルが生成されます。以下のシナリオでそれぞれを実証します。
Auth0認可の動作を示す3つのシナリオ
同じ4つの構成要素でも、設定が異なれば全く異なるセキュリティ結果をもたらします。
シナリオ1: 内部管理ポータル(ユーザー中心の制御)
- ユースケース: サポートエージェントは注文の読み取り(
read:orders)のみ可能ですが、在庫管理者は製品の読み取りと書き込み(read:products、write:products)が可能な内部小売アプリ。 - 設定:
- API RBAC: 有効
- Application Access Policy -> For user access: Allow
- 結果: アクセストークンのスコープはユーザーに割り当てられたロールのみによって決定されます。アプリケーション自体には権限の上限がなく、アクセスの管理を完全にAuth0のRBACに依存します。
サポートエージェントのデコードされたJWTスコープクレームの例。
{ "scope": "read:orders" }
在庫管理者のデコードされたJWTスコープクレームの例。
{ "scope": "read:products write:products" }
間違えた場合: RBACを有効にしてもユーザーへのロール割り当てを忘れた場合、トークンはスコープなしで到着し、APIはすべてのリクエストを拒否します。ロールが割り当てられていないRBACはフルアクセスではなく、アクセスなしを意味します。設計通りに機能する最小特権です。
モデルの使用場面: ユーザーの身元とロールのみが信頼シグナルとして必要な内部ツールや管理ポータル。
シナリオ2: サードパーティパートナーアプリ(アプリケーション中心の制御)
- ユースケース:
delete:analytics特権を持つ管理者がログインした場合でも、分析データの読み取り(read:analytics)のみが許可されるB2B SaaSパートナーアプリケーション。 - 設定:
- API RBAC: 無効
- Application Access Policy -> For user access: Allow via Client Grant
- 結果: アプリケーションのクライアントグラントが権限の上限を作成します。ユーザーの権限に関係なく、アプリケーション自体に付与されたスコープのみがトークンに含まれます。
管理者ユーザーの場合でもデコードされたJWTスコープクレームの例。
{ "scope": "read:analytics" }
管理者のdelete:analytics権限がトークンに到達することはありません。侵害された管理者セッションでもアプリケーションの権限境界を超えられないようにすることで、OWASP A01:2025アクセス制御の不備に直接対処します。
間違えた場合: ポリシーを設定してもクライアントグラントの設定を忘れた場合、アプリケーションには付与された権限がなく、トークンは空になり、すべてのAPI呼び出しが失敗します。
モデルの使用場面: 外部統合、パートナーアプリ、および誰が認証するかにかかわらずアプリケーションを制限する必要があるシナリオ。
シナリオ3: セキュアなモバイルアプリ(最小特権の原則の実践)
- ユースケース: 患者データの読み取り(
read:patient_history)のみが許可されているヘルスケアモバイルアプリ。使用する医師は別のフル機能Webポータルで使用するより広範な権限(write:patient_historyを含む)を持っています。 - 設定:
- API RBAC: 有効
- Application Access Policy -> For user access: Allow via Client Grant
- 結果: トークンの最終的なスコープはユーザーの権限とアプリケーションの権限の積集合です。医師のロールには含まれていても、モバイルアプリのクライアントグラントには含まれていないため、
write:patient_history権限は除外されます。
デコードされたJWTスコープクレームの例。
{ "scope": "read:patient_history" }
間違えた場合: RBACを有効にしてもポリシーを「Allow via Client Grant」ではなく「Allow」に設定した場合、クライアントグラントの上限は完全にバイパスされます。医師の完全なwrite:patient_history権限がモバイルアプリのトークンに流れ込み、モデルが防ぐように設計されている特権昇格をまさに引き起こします。
モデルの使用場面: モバイルアプリ、規制産業、マルチテナントSaaSなど、ユーザーとアプリケーションの両方を独立して信頼する必要があるシナリオ。
トークンのスコープの計算方法
アプリケーションが受け取るアクセストークンは、リクエストの瞬間に交差するいくつかの要因の計算結果です。Auth0は4つの入力を評価します。
- Audience: トークンが意図されているAPI。
- Requested Scopes: 認可リクエストでアプリケーションが要求する権限。
- User's Permissions: 割り当てられたロールを介してユーザーに付与された権限の完全なリスト。
- Application's Permissions: クライアントグラントを介してアプリケーションに明示的に付与された権限。
Auth0はAPIの設定に基づいて入力を処理し、最終的なトークンを発行します。すべての場合において、要求されたスコープはフィルターとして機能します。ユーザーとアプリの両方がより多くの権限を認可されていても、要求した以上のものを受け取ることはありません。
Audienceを指定すると、Auth0はデフォルトでJWTを発行します(デバッグのためにjwt.ioでデコードします)。Audienceが指定されていない場合、デフォルトで不透明なアクセストークンを配信します。トークン形式の詳細は、Auth0 Access Token documentationを確認ください。
3つのシナリオのロジックの概要
シナリオ
基本原則
主要なAuth0設定
最終的なトークンスコープ(簡略化)
1. 管理ポータル
ユーザーのロールが最優先
RBAC: 有効
Policy: Allow
Token = User Permissions ∩ Requested Scopes
2. パートナーアプリ
アプリケーションが最優先
RBAC: 無効
Policy: Allow via Client Grant
Token = App Permissions ∩ Requested Scopes
3. セキュアなモバイルアプリ
積集合が最優先
RBAC: 有効
Policy: Allow via Client Grant
Token = (User Permissions ∩ App Permissions) ∩ Requested Scopes
変化に強い認可戦略を構築するための4つのルール
verb:resource形式を使用して権限に名前を付ける。 API設定でread:orders、write:products、delete:analyticsなどの権限を定義します。規約はJWTのスコープクレームにきれいにマッピングされ、ポリシー監査を容易にし、チーム間で自己文書化されます。- 常に最小アクセスをデフォルトにする。 すべてのユーザー、ロール、クライアントグラントをゼロ権限で開始し、慎重に追加します。インシデント後に権限を取り消すよりも、後で権限を付与する方が常に簡単です。
- 粗粒度の認可ロジックをコードではなくAuth0に集中させる。 Auth0ダッシュボードでロール、権限、クライアントグラントを設定します。ビジネスルールが変更された場合、アプリケーションを再デプロイせずに1か所で更新します。
Auth0の利点
Auth0は3つの機能を通じて戦略を運用します。
- 分離されたポリシー管理: ロールと権限はコードベースではなくダッシュボードで設定されます。チームはデプロイなしでポリシーを更新します。
- Actionsによる拡張可能なロジック: Auth0 Actionsを使用すると、ログインフローにカスタム認可ロジックを注入できます。たとえば、ログイン後のActionを使用して、ダウンストリームフィルタリングのためにユーザーの部門をトークンに追加します。
- ユーザーとマシンの統一モデル: 同じAPIと権限の定義により、対話型のユーザーセッションとM2Mサービス通信の両方が保護され、並行する認可アーキテクチャの必要性が排除されます。
FGAによるロールの超越
シナリオ1の在庫管理者が割り当てられた倉庫の製品のみを管理すべきだとしたらどうでしょうか。あるいは、シナリオ3の医師が担当ユニットの患者の履歴のみを読み取るべきだとしたらどうでしょうか。
質問は特定のユーザーと特定のリソース間の関係を評価することを必要とします。ロールとスコープだけでは表現できないものです。リレーションシップベースアクセス制御(ReBAC)であり、まさにAuth0 FGAが構築された目的です。
実践的なシグナル: アクセスルールが「ユーザーはロールを持っているか」から「ユーザーは特定のオブジェクトと関係があるか」に移行したとき、標準のRBACを卒業したことになります。
実践する
- 実験: 機能はすべてのAuth0プランで利用できます。無料アカウントにサインアップし、本記事の3つのシナリオのいずれかを複製します。
- 深掘り: Role-Based Access ControlとAPI Authorizationの公式ドキュメントを読みます。
- 質問: Auth0 Community Forumに参加します。アーキテクト、開発者、Auth0エンジニアが現実世界の認可の課題について毎日議論しています。
認可は後付けする機能ではなく、アーキテクチャ上の決定です。Auth0は最初から正しく行うためのツールを提供します。