什么是 OAuth？委托访问、令牌和 PKCE 流程

Scrapeless Agent Browser 支持浏览器导航和基于会话的工作流，而 OAuth 权限仍由应用程序和授权服务器负责。

OAuth 是一个用于委托授权的框架

OAuth 是一种授权框架，它允许应用在不收集资源所有者这些资源的密码的情况下，获取对受保护资源的有限访问权限。 例如，用户可以授权某个日程安排工具读取日历，而日历服务则控制允许执行的操作。日程安排工具为该访问获取的是一种凭证，而不是用户可重复使用的密码。

The OAuth 授权框架 定义了各个角色和核心交互。资源所有者控制相关资源，客户端应用程序请求访问，授权服务器根据其策略授予凭据，而资源服务器托管受保护的 API。一个组织可以同时运行这两类服务器角色，但将角色区分开来有助于说明身份验证、权限决策以及令牌验证分别在何处发生。

令牌授权的范围比对账户操作的全权许可更窄。访问可以通过范围、目标资源、时长以及授权服务器的策略来加以限制。资源服务器仍会检查该操作是否被允许。一个同意界面会描述所请求的访问，而实际授予的凭证以及服务器的强制执行，则共同决定应用在获得同意后实际能够执行的操作。

授权和认证回答的是不同的问题

授权决定应用程序可以执行哪些访问；认证在特定环境中建立一个身份。OAuth 可能涉及用户在授权服务器上登录，但这种交互并不会自动为客户端提供适用于其自身登录系统的标准化身份声明。将任意访问令牌视为登录凭证可能会导致令牌替换和受众问题。

The OpenID Connect 身份层 在 OAuth 之上增加了认证功能，并为客户端定义了一个用于验证的 ID 令牌。访问令牌是为资源服务准备的，而 ID 令牌则用于处理客户端的身份验证上下文。这一区别在标准中是清晰可见的，并且在应用程序设计中也应保持清晰。向不相关的 API 发送 ID 令牌并不等同于出示正确的访问令牌。

对于登录产品，应选择明确支持所需身份协议的供应商集成，并使用该协议验证其令牌。对于委托的 API 访问，应请求最低限度且合适的权限，并仅将获得的访问凭据发送到其预期服务。单个面向用户的按钮可以隐藏这两种工作流，因此应检查实际协议约定，而不是把每一种社交登录行为都统称为 OAuth 登录。

授权代码将浏览器端授权与令牌使用分离

授权代码流程会将用户导向授权服务器，由授权服务器在需要时对用户进行身份验证并评估访问请求。获批后，浏览器会携带一个短期有效的授权代码返回到已注册的客户端重定向地址。随后，客户端在令牌端点使用适合其客户端类型的参数和认证方式，将该授权代码交换为令牌。

代码不是用于读取日历条目或其他受保护记录的 API 凭据。它的目的是将前端通道的授权交互与后续的令牌交换关联起来。保持对重定向 URI 的严格验证，并将响应绑定到客户端发起的事务。对于在意外来源接收到的回调，或者缺少预期事务上下文的回调，不应将其视为已认证的应用会话。

客户端注册描述了其重定向位置和允许的授权类型等详细信息。能够保护凭据的服务器应用程序与通过浏览器分发的公共应用程序具有不同的能力。不要将服务器端客户端密钥复制到可下载的 JavaScript 中。无论在控制台中附加了什么标签，应用程序的分发模型都决定了该值是否能够被保密。

PKCE 保护代码交换

PKCE（Proof Key for Code Exchange，授权码校验机制）通过一个与事务相关的验证器将授权请求与令牌交换绑定在一起。客户端从验证器派生出一个质询，并在授权请求中携带该质询。在令牌端点，客户端提交验证器，使服务器能够确认当前的交换属于同一次发起的事务。

The PKCE 机制 解决授权码拦截问题。PKCE 并不会将公共应用程序变成机密客户端，验证器也不是永久的客户端密码。应在特定事务中生成并保留验证器，妥善保护它，并使用受支持的质询方法，以避免在授权请求中暴露验证器。

The 当前 OAuth 安全最佳实践 在授权码流程中对公共客户端要求使用 PKCE，并建议机密客户端也使用。它还处理精确重定向匹配、代码注入和令牌泄露等问题。通过受维护的 OAuth 实现来应用这些要求，而不是从一些松散相关的代码片段拼装出一个流程。即使是正确的库，也仍然需要正确配置发行方、重定向地址和资源。

访问令牌和刷新令牌拥有不同的生命周期

访问令牌携带或引用资源服务所需的授权。其格式并未被通用 OAuth 框架固定：服务可以使用不透明值或结构化令牌。客户端应依赖文档化的响应字段和资源要求，而不是假定每个访问令牌都是可读的 JSON Web Token。

刷新令牌是一种不同的凭证，用于在授权服务器上获取访问令牌。它不应被发送到普通的资源 API。服务器是否签发刷新令牌、有效期有多长以及施加何种保护，取决于客户端和服务商的策略。应将其视为重要机密进行保护，因为它的生命周期可能超过单个访问令牌。

吊销也有定义好的接口，而不仅仅是通过删除本地字符串来隐含实现。 OAuth 令牌吊销机制 允许客户端通知授权服务器某个令牌已不再需要。本地登出、授权撤销以及终止每个应用会话可能产生不同效果。记录这些效果，以便用户了解断开某个集成实际上会改变什么。

范围、受众和服务器策略限制访问

Scope 描述在授权系统词汇内被请求或被授予的能力。Scope 的名称和含义属于服务提供方。一个偏重读取的 scope 仍可能暴露敏感记录，因此只请求产品功能所必需的权限，并解释原因。应用不应仅仅为了将来开发更方便就请求广泛的写入权限。

目标资源或受众是另一道边界。为某一服务签发的令牌不应被另一服务接受为可互换的授权。资源服务器必须使用选定的令牌机制验证相关的发行方、受众、过期时间和授权细节。仅有有效签名并不能证明某个凭证适用于当前请求的操作。

客户端凭证流程用于在不代表用户委托同意的场景下处理应用访问。面向设备的流程则应对其他交互约束。应选择与实际应用类型相匹配、且受支持的授权模式，而不是强迫所有产品都通过某个熟悉的流程。某项服务文档中出现 OAuth，并不意味着每种授权类型、scope 或客户端类型都对每个账号可用。

将浏览器状态与 OAuth 凭证分离

浏览器 Cookie、应用会话与 OAuth 凭证是相关但生命周期不同的实现关注点。浏览器可以保持登录状态，而 API 令牌已经过期；某个浏览器视图关闭后，应用仍然可以持有有效的委托令牌。应在持有相关凭证的组件处诊断权限失败，而不是把浏览器状态复制到无关服务中。

“ Scrapeless API 密钥处理要求 ”描述了用于访问 Scrapeless 产品的另一种凭证。Scrapeless API 密钥并不是目标网站的 OAuth 访问令牌。相关的 API 认证方法 有助于区分不同的凭证方案，而 Scrapeless pricing 涵盖的是服务使用情况，而非第三方授权权利。

在扩展委托集成前进行审查

一个委托集成应具有清晰的权限清单。记录发行方、目标资源、请求的 scope、客户端类型、重定向位置、凭证存储方式以及断开连接行为。将普通的应用遥测与携带令牌的请求数据分离，以免常规日志变成不受控的凭证存储。使用已授权账号和文档化的访问级别测试权限边界。

一个假设的日历集成可以从对一个用户批准功能的只读访问开始。其验收标准应包括：使用正确的账号、仅访问被允许的日历资源、具备可用的断开连接路径，以及在客户端可见日志中不出现任何机密信息。只有在有具体功能需要时才扩展权限。这种自律让授权同意请求更易于解释，并限制凭证泄露带来的后果。

结论

OAuth 通过定义好的角色、凭证和服务器策略来委派特定访问权限。根据实际客户端类型选择授权流程，在需要时使用 PKCE，并将身份断言与资源访问令牌分开。一个可维护的集成会在处理敏感账号数据之前，就明确其作用域、存储边界和断开连接行为。