1. Introduction (简介)

1. Introduction (简介)

多年对 OAuth 2.0 授权框架 (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 实现与部署为此采用专有参数. 本规范旨在今后为此类需求提供标准化且可互操作的替代方案, 以取代专有做法.