1. Introduction (はじめに)

1. Introduction (はじめに)

OAuth 2.0 Authorization Framework [RFC6749] の多年にわたる運用と実装の経験から, ある状況 (例: 多様な多数のリソースにサービスを提供する認可サーバー) では, クライアントが認可サーバーに対し, 要求しているアクセストークン (access token) をどこで使用する意図があるかを明示的に伝える必要があることが明らかになった.

アクセストークンを処理する保護リソース (protected resource, 別名 resource server (リソースサーバー), application, API 等) を把握することで, 認可サーバーはそのエンティティに必要な形でトークンを構成できる. 例えば, トークン (またはトークン内の内容) を特定のリソース向けに適切に暗号化するには, どのリソースがトークンを受信して復号するかを知る必要がある. さらに, リソースごとにトークンに含まれる (または参照される) データへの要件が異なることが多く, クライアントがトークンを使用する意図のあるリソースを把握できれば, 認可サーバーはそれに応じてトークンを発行できる.

アクセストークンの意図した受信者 (recipient(s)) の具体的知識は, トークン自体のセキュリティ特性を高めるのにも役立つ. Bearer token (ベアラートークン) は現在最も一般的に用いられる OAuth アクセストークンの種類であり, トークンを保有する当事者は誰でも関連リソースにアクセスできる. 悪用を防ぐには複数の重要なセキュリティ前提が成立しなければならず, その一つはアクセストークンは特定の保護リソースおよび特定のスコープ (scope) でのみ有効でなければならないことである. 例えば [RFC6750] の第 5.2 節は, トークンのリダイレクト (token redirect) を防ぐためトークンに意図した受信者を含めることを規定する. 認可サーバーがアクセストークンを処理するリソースを知れば, そのトークンの意図した audience (オーディエンス) を与えられたリソースに限定し, 他のリソースでは成功裏に使用できないようにできる.

OAuth の scope は [RFC6749] 第 3.3 節にあり, 保護リソースの場所や識別を伝えるために過負荷されることもあるが, 常に実現可能または望ましいわけではない. scope は通常, どのようなアクセスが要求されているかについてであり, アクセスがどこで償還されるかではない (例: "email", "admin:org", "user_photos", "channels:read", "channels:write" は, 実運用で見られる scope 値のごく一部で, アクセスの種類のみを示し場所や識別は示さない).

一部の状況とデプロイメントでは, クライアントが認可サーバーに対し要求しているアクセストークンをどこで使用する意図があるかを伝える手段は重要かつ有用である. OAuth 2.0 の多数の実装とデプロイメントはすでにその目的で独自パラメーターを用いてきた. 本仕様は, 今後そのような独自アプローチに代わる標準化され相互運用可能な代替を提供することを目指す.