---
title: "スコープ、ロール、クライアントグラントで解説するAuth0認可ガイド
"
description: "スコープ、ロール、クライアントグラントの関係を理解し、Auth0認可をマスターする方法を学ぶことができます。"
authors:
  - name: "Andre Hochstein"
    url: "https://auth0.com/blog/authors/andre-hochstein/"
  - name: "Jan Singer"
    url: "https://auth0.com/blog/authors/jan-singer/"
date: "May 19, 2026"
category: "Identity & Security"
tags: ["authorization", "client grants", "scopes", "roles"]
url: "https://auth0.com/blog/jp-auth0-authorization-guide-scopes-roles-client-grants/"
---

# スコープ、ロール、クライアントグラントで解説するAuth0認可ガイド


>本記事は「[A Practical Guide to Scopes, Roles, Permissions and Client Grants](https://auth0.com/blog/auth0-authorization-guide-scopes-roles-client-grants/)」を翻訳した記事です。


<style>

/* Increases spacing between bullet points */

li {padding-bottom: .7em; }

* Style a table. Add borders, center table, and reduce font size. */

table {

width: 90%;

margin: 2.4rem auto !important;

border-collapse: collapse;

font-size: .9em;

}

table, td, th {

border: 1px solid;

}

table th {

line-height: normal;

padding: .8em;

}

td {

padding: .8em;

line-height: normal;

}

</style>

ユーザーデータを扱うすべてのアプリケーションは認可の決定を下しますが、多くは誤った決定を下しています。[アクセス制御の不備](https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/)は[2021年以来OWASPトップ10](https://auth0.com/blog/why-broken-access-control-still-dominates-owasp-top-10/)の首位を占めており、Webアプリケーションにおける最大のセキュリティ脅威であり続けています。

「誰であるか」と「何ができるか」のギャップで侵害が発生します。両者を正確に定義します。

* **認証**: ログインプロンプト、パスワードチェック、多要素認証など、身元を確認するプロセスです。「誰であるか」に答えます。
* **認可**: 身元が確立された後にポリシーを適用するプロセスです。「何を許可されているか」に答えます。

## 認可がアプリケーションの第一の防衛線である理由

堅牢な認可戦略はアプリケーションの最も重要な内部保護手段です。背後にある基本原則はシンプルかつ強力であり、[**最小特権の原則**](https://auth0.com/blog/oauth2-access-tokens-and-principle-of-least-privilege/)と呼ばれます。

ユーザーやアプリケーションは正当な機能を実行するために必要な最小限の権限セットのみを受け取るべきであり、それ以上は不要です。正しく実装することで攻撃対象領域を減らし、認可に関連する技術的負債を排除します。

Auth0で正しく実装するには、4つのコアコンポーネントを理解する必要があります。

## Auth0認可のコアコンポーネント

各コンポーネントは誰がどのコンテキストで何を行えるかを決定する上で、明確な役割を果たします。

1. **ロール:** ロールはユーザーに割り当てられる権限の名前付きコレクションです。多数の権限を直接割り当てる代わりに、ロール(*在庫管理者*など)を作成して関連する権限を割り当て、ユーザーに割り当てます。
2. **権限:** 権限はAPIで定義されるきめ細かな操作です(例:*read:orders*)。権限は認可の最も基本的な単位であり、Auth0ダッシュボードのAPI設定で定義されます。
3. **クライアントグラント:** クライアントグラントはアプリケーション自体が要求を認可される権限を定義します。クライアントグラントはアプリケーション自体に直接権限を割り当てます。2つの目的を果たします。[クライアントクレデンシャルフロー](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-credentials-flow)を介したMachine-to-Machine(M2M)通信の保護と、ユーザー向けアプリケーションの**権限の上限**としての機能です。誰がログインするかに関係なく最小特権を強制します。
4. **スコープ:** スコープは二重の役割を果たします。認可フロー中にアプリケーションが*要求する*権限であり、Auth0が設定を評価した後にアクセストークンで実際に*付与される*権限でもあります。要求と付与のギャップにセキュリティポリシーが存在します。権限、特権、スコープの違いに関する詳細は、以前のブログ[Permissions, Privileges, and Scopes](https://auth0.com/blog/permissions-privileges-and-scopes/)を確認ください。

## トークン権限を制御する2つの設定

上記の4つのコンポーネントは定義する*対象*です。以下の2つの設定はアクセストークンを発行する際にAuth0がコンポーネントを*どのように*組み合わせるかを制御します。

* **RBAC(ロールベースアクセス制御の有効化):** 有効にすると、Auth0は認可フロー中にユーザーに割り当てられたロールと関連する権限を評価します。無効にすると、ユーザーレベルの権限はトークンに考慮されず、ユーザーのロールは事実上無視されます。

**Auth0ダッシュボードのAPIs > [対象のAPI] > Settings > RBAC Settings**

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/2E4DuZ0gR9XT2F5pN5jAaS/cd653132d5b42830a6ab04fdadb67d2f/Auth0DashboardAPIs.png" alt="Auth0 Dashboard RBAC Settings" style="width:100%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>

RBAC設定までスクロールし、Enable RBACを切り替えます。

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/1ttymGiCeQkpvccXO504US/a7f9a3c756f18f83b25c5b51b4f5b862/Auth0DashboardEnableRBAC.png" alt="Auth0 Dashboard RBAC settings" style="width:100%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>

* **Application Access Policy(ユーザーアクセス用):** アプリケーションのクライアントグラントが権限の上限として機能するかどうかを決定します。

* **Allow:** アプリケーションは制限なしで信頼されます。トークンスコープはユーザーの権限のみから派生します(有効にするにはRBACを有効にする必要があります)。
* **Allow via Client Grant:** アプリケーションのクライアントグラントが厳格な境界になります。ユーザーのロールが認可するものに関係なく、アプリケーションに明示的に付与された権限のみがトークンに表示されます。
* **Deny:** アプリケーションは信頼されず、結果としてAPI権限へのアクセスが制限されます。

**Auth0ダッシュボードのAPIs > [対象のAPI] > Application Access**

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/5OWbwWG2ioRp6e0ln0HnJo/63229a941a491879cca76e133f25e162/Auth0DashboardApplicationAccess.png" alt="Auth0 Dashboard APIs Application Access" style="width:100%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>

APIの「Edit」ボタンをクリックし、「Allow via client-grant」ポリシーの特定の権限を付与します。

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/5TTwWvCGrgX08rLes8JcIM/e382412f9f5aab2c9df9a8840fa59424/Auth0DashboardClientGrant.png" alt="Auth0 Dashboard Client Grant" style="width:80%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>

2つの設定の組み合わせにより、根本的に異なる3つの認可モデルが生成されます。以下のシナリオでそれぞれを実証します。

## Auth0認可の動作を示す3つのシナリオ

同じ4つの構成要素でも、設定が異なれば全く異なるセキュリティ結果をもたらします。

### シナリオ1: 内部管理ポータル(ユーザー中心の制御)

* **ユースケース**: **サポートエージェント**は注文の読み取り(`read:orders`)のみ可能ですが、**在庫管理者**は製品の読み取りと書き込み(`read:products`、`write:products`)が可能な内部小売アプリ。
* **設定**:
* **API RBAC**: 有効
* **Application Access Policy -> For user access**: Allow
* **結果**: アクセストークンのスコープはユーザーに割り当てられたロールのみによって決定されます。アプリケーション自体には権限の上限がなく、アクセスの管理を完全にAuth0のRBACに依存します。

サポートエージェントのデコードされたJWTスコープクレームの例。

```json
{
"scope": "read:orders"
}
```

在庫管理者のデコードされたJWTスコープクレームの例。

```json
{
"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スコープクレームの例。

```json
{
"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スコープクレームの例。

```json
{
"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](http://jwt.io)でデコードします)。Audienceが指定されていない場合、デフォルトで不透明なアクセストークンを配信します。トークン形式の詳細は、[Auth0 Access Token documentation](https://auth0.com/docs/secure/tokens/access-tokens)を確認ください。

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/6i5fHglTUbTCfCpdesWxzr/c4d16408b9d2adb47ab77da8c3866f92/ScopesInUserAccessTokens.png" alt="A Summary of Logic from the Three Scenarios" style="width:80%; margin: 1em auto; border: solid black 0px; border-radius: 0px;">
</picture>

3つのシナリオのロジックの概要
シナリオ
基本原則
主要なAuth0設定
最終的なトークンスコープ(簡略化)
**1. 管理ポータル**
ユーザーのロールが最優先
**RBAC:** 有効<br />  **Policy:** Allow
`Token = User Permissions ∩ Requested Scopes`
**2. パートナーアプリ**
アプリケーションが最優先
**RBAC:** 無効<br />  **Policy:** Allow via Client Grant
`Token = App Permissions ∩ Requested Scopes`
**3. セキュアなモバイルアプリ**
積集合が最優先
**RBAC:** 有効<br/>  **Policy:** Allow via Client Grant
`Token = (User Permissions ∩ App Permissions) ∩ Requested Scopes`

<div class="alert alert-info alert-icon">
<i class="icon-budicon-487 icon-info"></i>
<b>トークンスコープは認可の*クレーム*であり、強制ではありません。APIはすべてのリクエストで`scope`クレームを検証する必要があります。ほとんどのフレームワークでは、各エンドポイントに必要なスコープとデコードされたJWTに存在する[スコープ](https://auth0.com/blog/on-the-nature-of-oauth2-scopes)を比較するスコープチェックミドルウェアを追加することを意味します。必要なスコープが欠落している場合は、`403 Forbidden`を返します。Auth0の[API quickstarts](https://auth0.com/docs/quickstart/backend)は、すべての主要な言語とフレームワークの実装例を提供します。</b><br>
</div>

## 変化に強い認可戦略を構築するための4つのルール

1. **`verb:resource`形式を使用して権限に名前を付ける。** API設定で`read:orders`、`write:products`、`delete:analytics`などの権限を定義します。規約はJWTのスコープクレームにきれいにマッピングされ、ポリシー監査を容易にし、チーム間で自己文書化されます。
2. **常に最小アクセスをデフォルトにする。** すべてのユーザー、ロール、クライアントグラントをゼロ権限で開始し、慎重に追加します。インシデント後に権限を取り消すよりも、後で権限を付与する方が常に簡単です。
3. **粗粒度の認可ロジックをコードではなくAuth0に集中させる。** Auth0ダッシュボードでロール、権限、クライアントグラントを設定します。ビジネスルールが変更された場合、アプリケーションを再デプロイせずに1か所で更新します。

## Auth0の利点

Auth0は3つの機能を通じて戦略を運用します。

* **分離されたポリシー管理:** ロールと権限はコードベースではなくダッシュボードで設定されます。チームはデプロイなしでポリシーを更新します。
* **Actionsによる拡張可能なロジック:** [Auth0 Actions](https://auth0.com/docs/customize/actions/actions-overview)を使用すると、ログインフローにカスタム認可ロジックを注入できます。たとえば、ログイン後のActionを使用して、ダウンストリームフィルタリングのためにユーザーの部門をトークンに追加します。
* **ユーザーとマシンの統一モデル:** 同じAPIと権限の定義により、対話型のユーザーセッションとM2Mサービス通信の両方が保護され、並行する認可アーキテクチャの必要性が排除されます。

## FGAによるロールの超越

シナリオ1の在庫管理者が*割り当てられた倉庫の*製品のみを管理すべきだとしたらどうでしょうか。あるいは、シナリオ3の医師が*担当ユニットの患者の*履歴のみを読み取るべきだとしたらどうでしょうか。

質問は特定のユーザーと特定のリソース間の**関係**を評価することを必要とします。ロールとスコープだけでは表現できないものです。**リレーションシップベースアクセス制御(ReBAC)**であり、まさに[Auth0 FGA](https://auth0.com/blog/relationship-based-access-control-rebac/)が構築された目的です。

**実践的なシグナル:** アクセスルールが「ユーザーはロールを持っているか」から「ユーザーは特定のオブジェクトと関係があるか」に移行したとき、標準のRBACを卒業したことになります。

## 実践する

1. **実験:** 機能はすべてのAuth0プランで利用できます。[無料アカウントにサインアップ](https://auth0.com/signup)し、本記事の3つのシナリオのいずれかを複製します。
2. **深掘り:** [Role-Based Access Control](https://auth0.com/docs/manage-users/access-control/rbac)と[API Authorization](https://auth0.com/docs/get-started/set-up-apis)の公式ドキュメントを読みます。
3. **質問:** [Auth0 Community Forum](https://community.auth0.com/)に参加します。アーキテクト、開発者、Auth0エンジニアが現実世界の認可の課題について毎日議論しています。

**認可は後付けする機能ではなく、アーキテクチャ上の決定です。Auth0は最初から正しく行うためのツールを提供します。**