OAuth 是如何工作的？

Scrapeless Agent Browser 为授权的网站交互提供云浏览器会话，而你的应用程序仍然负责其集成所使用的 OAuth 权限和令牌。

OAuth 是如何工作的？

OAuth 允许应用程序通过授权服务器获取对受保护资源的有限访问，而无需让应用程序收集资源所有者的密码。应用程序会接收一个代表已批准授权的访问令牌，并将该令牌提供给资源服务器。资源服务器负责决定该令牌是否授权执行所请求的操作。

OAuth 是一种授权框架。一个常见的登录按钮可能会涉及 OAuth，但要证明登录者的身份则需要身份协议及其验证规则。将权限与身份分离，可以防止应用程序将任何成功的令牌交换视为足以证明用户身份的证据。

谁参与了 OAuth 流程？

OAuth 流程涉及资源所有者、客户端、授权服务器和资源服务器。资源所有者可以授予访问权限。客户端是请求该访问权限的应用程序。授权服务器评估请求并签发令牌。资源服务器托管受保护的数据或操作。

The OAuth 授权框架 定义了这些角色。单个组织可以同时运行这两种服务器角色，但其职责仍然不同。在授权服务器成功完成身份验证并不会自动授予在资源服务器上的所有操作权限。

作用域在某个服务的术语体系中命名了一项被请求的权限。日历集成可能只请求读取日程事件的权限，而不是修改它们。提供方定义这些名称的含义，以及是否需要用户、管理员或其他策略来批准它们。客户端应当只请求其实际目的所必需的访问权限。

客户端类型很重要。服务器应用程序通常可以在受控的后端保护凭证。发送到浏览器或移动设备的代码不能将嵌入的客户端密钥视为机密。客户端注册和所选流程必须反映这一边界。

在使用 PKCE 的授权码模式中会发生什么？

授权码流程会将用户引导至授权服务器，在已注册的客户端重定向地址返回一个代码，并将该代码交换为令牌。PKCE 添加了一个验证器和由其派生的质询，用以将授权请求与后续的交换关联起来。

1. 客户端创建一个新的授权事务，其中包含验证器及其派生的质询，并记录验证响应所需的状态。
2. 客户端会将浏览器重定向到授权服务器，并携带已注册的客户端标识、重定向地址、请求的权限以及质询。
3. 授权服务器根据需要对用户进行身份验证，并评估同意与策略。
4. 授权服务器将授权码返回到客户端被允许的重定向地址。
5. 客户端在令牌端点与验证器一起验证响应并交换代码，在适用情况下使用所需的客户端身份验证。
6. 客户端将访问令牌呈交给目标资源服务器，以在授权范围内执行操作。

The PKCE 质询和验证器机制 当服务器正确执行绑定时，仅仅持有被拦截的代码本身不足以完成交换。验证器是特定于该交易的，不应变成共享的应用程序常量。

PKCE 并不会使其他验证都变成可选。客户端仍然必须使用正确的服务器、验证返回的响应、保护其事务状态，并遵守重定向规则。请使用与提供方匹配的、受维护的 OAuth 实现，而不是从不相关的代码片段中拼凑出一个流程。

访问令牌、刷新令牌和 ID 令牌分别是什么意思？

访问令牌授权对资源的访问，刷新令牌可以在服务器策略下获取新的访问令牌，而 ID 令牌在 OpenID Connect 中传递认证信息。这些令牌具有不同的受众和验证要求。将一种令牌当作另一种来使用可能会导致授权错误或安全漏洞。

访问令牌可以是不可见（不透明）的，也可以使用结构化格式。不要假设每个 OAuth 令牌都是 JWT，或者认为对令牌进行解码就能证明其有效。资源服务器的约定决定了必须如何检查发行方、受众、过期时间、签名或服务器端令牌状态。

刷新令牌是可选的。其签发方式、存储要求、轮换行为和撤销机制因提供方而异。客户端不应因为初始授权成功就假定可以获得永久访问。范围变更和账户策略可能会改变后续操作被允许的内容。

OpenID Connect 的身份层 在 OAuth 之上定义 ID 令牌和身份验证声明。使用登录功能的客户端必须根据该协议及其提供程序配置来验证身份响应。

客户端必须保护哪些边界？

客户端必须保护重定向处理、事务关联、凭据以及每一个令牌的目的地。OAuth 集成是一系列信任决策，而不仅仅是一串 HTTP 请求。为某个 API 准备的令牌，不应仅因为两个服务都接受 Authorization 头，就被转发给无关的服务。

本文 《OAuth 安全最佳当前实践》 为流程选择和攻击防护提供了当前安全基线。公共客户端必须使用 PKCE；也推荐机密客户端使用 PKCE。重定向匹配以及防止授权响应注入依然是设计中必不可少的部分。

将服务器端密钥存储在部署中批准的机密存储中。限制对刷新令牌的访问，避免在 URL、日志、分析或支持截图中放置令牌值。授权码在仍可使用期间同样是敏感信息，因此回调日志记录需要谨慎配置。

不要选择资源所有者密码模式来图省事直接收集用户凭据。当前安全指南已经否定该模式。用户同意和管理员策略应通过授权服务器所支持的体验来处理。

OAuth 与浏览器登录和 API 密钥有何不同？

浏览器登录会话维护网站状态，API 密钥在服务的密钥策略下标识访问，OAuth 则表示授权授予。这些机制可以出现在同一个工作流中，但不能互换。网站 Cookie 不会自动变成委托的 API 凭据。

Scrapeless Agent Browser 为您的应用被授权执行的交互提供浏览器环境。它并不是该浏览器访问的每一个网站的授权服务器。打开同意页并不赋予自动化流程在用户指示之外批准权限的权利。

本文 Scrapeless API key handling requirements 描述了 Scrapeless 服务凭据的使用和保护方式。请遵循该已文档化的密钥契约，而不是附加 OAuth bearer 前缀，或将 Scrapeless 密钥当作由无关提供方签发的令牌。

本文 bounded collection worker deployment pattern 在将机密与可复用应用代码分离时具有参考意义。OAuth 集成同样需要运行时凭据处理、访问控制，以及在工作进程的用途与授予它的权限之间建立清晰边界。

如何设计一个委托式集成？

委托式集成从明确定义的用户操作和尽可能小的有用权限集开始。考虑一个说明性的报表应用，它只读取用户的日历空闲情况。该应用注册被允许的回调，选择提供方支持的授权流程，并请求用于可用性信息所需的权限，而不是广泛的账户管理权限。

回调完成后，后端验证该事务，并安全地存储获准的凭据材料。资源请求会以目标 API 为对象，并在授予的 scope 下进行评估。应用记录连接状态，同时不在面向用户的日志中暴露令牌。

断开连接需要显式设计。删除本地存储的凭据，并在合适时使用提供方支持的吊销控制。向用户说明断开应用是否也会吊销服务器端权限。这些操作相关，但并不总是产生相同效果。

在测试成功路径的同时，也要测试被拒同意、不匹配的回调、已过期的事务状态以及权限不足。受控的提供方测试环境可以验证行为，而无需将示例性的流程视为真实的授权运行。本概念示例并不声明存在任何真实账户授权授予。

结论

沿着权限授予来追踪 OAuth：谁批准了它、哪个客户端收到了它、哪个资源接受它，以及它在多长时间内保持有用。保持浏览器会话与服务 API 密钥相互独立。对于基于浏览器的工作流，请将 Scrapeless pricing 与目标提供方的权限和 API 策略分开单独审阅。