4つの役割
OAuth 2.0 には4つの主要な役割（ロール）があります。 それぞれの役割と関係性を、マンションの例えで理解しましょう。
保護されたリソースの所有者。通常はエンドユーザー（あなた自身）です。
例え話
マンションの住人。自分の部屋の鍵と、誰を招くかの決定権を持っている。
具体例
- -Google アカウントを持つユーザー
- -GitHub リポジトリのオーナー
リソースオーナーの代わりにリソースにアクセスしたいアプリケーション。
例え話
清掃業者。住人（リソースオーナー）の許可を得て、部屋に入りたい。
具体例
- -写真印刷アプリ
- -タスク管理ツール
- -サードパーティの分析ツール
リソースオーナーを認証し、クライアントにアクセストークンを発行するサーバー。
例え話
マンションの管理会社。住人の本人確認をし、清掃業者に制限付きの鍵を発行する。
具体例
- -Google の認証サーバー
- -Auth0
- -Keycloak
保護されたリソースをホストし、アクセストークンを検証してリソースを提供するサーバー。
例え話
マンションのドアのオートロック。有効な鍵（トークン）を持っている人だけを通す。
具体例
- -Google Photos API
- -GitHub API
- -Twitter API
4つの役割の関係
# 写真印刷アプリの例
[リソースオーナー] ユーザー (あなた)
|
| 1. 「Google Photos の写真を使って印刷したい」
v
[クライアント] 写真印刷アプリ
|
| 2. 「Google に許可をもらってきてください」
v
[認可サーバー] Google の認証画面
|
| 3. ユーザーが許可 → アクセストークン発行
v
[クライアント] 写真印刷アプリ (トークン取得)
|
| 4. トークンを使って写真をリクエスト
v
[リソースサーバー] Google Photos API
|
| 5. トークンを検証 → 写真データを返す
v
[クライアント] 写真を受け取り、印刷処理へ
知っておきたいポイント
認可サーバーとリソースサーバーは同じ場合もある: 小規模なシステムでは、1つのサーバーが両方の役割を担うことがあります。
クライアントは必ずしもブラウザアプリとは限らない: モバイルアプリ、サーバーサイドアプリ、CLI ツールなど、様々な形態があります。
リソースオーナーは人間とは限らない: マシン間通信では、サービスアカウントがリソースオーナーになることもあります。