什么是OAuth？角色、流程、令牌和安全基础知识

无抓取抓取API在x-api-token头中使用账户API密钥，提供了与OAuth的委派授权模型的具体对比。

什么是OAuth？

OAuth是一个用于委派授权的框架。它允许应用程序在不要求用户输入拥有这些资源的服务密码的情况下请求有限的访问受保护资源。用户与授权服务器互动，批准请求的访问，客户端接收到令牌而不是用户的主凭据。

RFC 6749定义了OAuth 2.0授权框架。它描述了角色、协议端点、授权授权、访问令牌和刷新令牌。后续文件更新框架并为当前部署提供安全指南。

OAuth还可以授权代表自己行动的机器客户端。客户端凭证授予旨在为在建立服务关系下访问资源的保密客户端。该流程与用户批准第三方应用程序不同。

OAuth的四个角色

一个组织可以同时运营授权服务器和资源服务器，但它们依然保持独立的协议角色。保持角色清晰有助于团队在正确的边界放置验证和策略。

授权码流程是如何工作的

1. 客户端创建授权请求。 它将浏览器发送到授权端点，带有客户端标识符、请求的范围、重定向URI、状态和PKCE挑战。
2. 授权服务器处理用户交互。 在需要时验证用户并显示正在请求的访问。
3. 资源所有者授予或拒绝访问。 同意和政策决定是否发行授权码。
4. 浏览器返回到注册的重定向URI。 响应包括授权码和状态值。
5. 客户端验证响应。 它将状态与绑定到发起浏览器会话的值进行比较。
6. 客户端交换代码。 它通过代码和 PKCE 验证器调用令牌端点；机密客户端也使用其批准的身份验证方法。
7. 授权服务器发放令牌。 响应通常包括访问令牌，并可能在服务器政策下包括刷新令牌。
8. 客户端调用资源服务器。 资源服务器验证令牌，并强制执行范围、受众和资源级政策。

授权码是中介凭证，而不是最终的 API 令牌。直接通过浏览器面向的授权响应发送访问令牌会将其暴露于更多前端渠道表面。当前的做法是在令牌端点保持访问令牌交换，并根据需要使用 PKCE 和客户端身份验证保护它。

什么是 PKCE？

PKCE 代表代码交换的证明密钥。客户端为一次授权尝试生成高熵验证器，并随授权请求发送派生挑战。在代码交换过程中，客户端提出验证器。只有在值匹配时，授权服务器才会重新计算挑战并接受代码。

RFC 7636 定义了 PKCE。它用于保护从公共客户端重定向中拦截的授权码，当前的安全指导将其广泛应用于授权码流程。请使用标准配置文件支持的安全挑战方法，而不是简单的验证器转换。

PKCE 并不会取代状态。PKCE 将代码交换绑定到发起客户端实例。状态将授权响应绑定到浏览器交互，并帮助防止跨站请求伪造和客户端会话处理中的混淆。

访问令牌和刷新令牌

访问令牌代表授予给客户端的权限。资源服务器使用它来决定请求是否可以访问请求的资源和操作。令牌可以是不透明的，需要透视或服务器端查找，或在定义的签名令牌配置文件下自我包含。

刷新令牌允许客户端请求新的访问令牌而无需其他用户交互。它通常仅发送给授权服务器，而不是资源服务器。刷新令牌是有价值的长期凭证，需要受保护的存储、客户端绑定、由服务器定义的轮换或重播控制，以及撤销支持。

令牌格式与 OAuth 流程是分开的。OAuth 不要求使用 JSON Web 令牌。当立即的中央政策和撤销重要时，不透明访问令牌可能更可取。自我包含的令牌可以减少查找需求，但需要仔细验证颁发者、受众、签名、时间声明和配置文件允许的算法。

范围、受众和同意

范围是由授权服务器定义的字符串，表示权限或访问类别。客户端请求范围，但服务器可能根据同意和政策授予更少的权限。范围名称应描述有意义的能力，而不是镜像每个内部端点。

受众标识预期的资源服务器或资源集合。针对一个 API 发放的令牌不应被无关的 API 接受，仅仅因为其签名是有效的。资源服务器必须验证他们期望的受众和颁发者。

同意并不是政策的替代品。用户不应该能够授予用户不持有的权限。授权服务器和资源服务器仍然强制执行租户、角色、所有权、风险和资源级限制造。

公共和机密客户端

机密客户端可以通过其操作员控制的环境保护凭证，例如后端服务。公共客户端在不能保留秘密的地方运行，例如用户分发的浏览器或安装的应用程序。在每个公共应用程序副本中运输相同的客户端秘密并不会使这些副本变为机密。

公共客户端依赖 PKCE、精确的重定向处理、平台保护和有限的令牌权限，而不是共享的嵌入秘密。机密客户端在令牌端点使用授权服务器批准的身份验证方法，并且必须通过秘密生命周期保护这些凭证。

OAuth 和 API 密钥

API 密钥通常直接标识客户端或项目。它在受控的服务器到服务器关系中表现良好，其中帐户拥有者配置凭证。OAuth 增加了获取令牌的协议，包括用户委派的访问权限以及同意和范围。

当后端服务访问其自己的帐户，并且提供者的密钥模型提供足够的限制时，请使用 API 密钥。当第三方客户端需要代表用户进行有限访问时，当权限需要独立撤销时，或生态系统需要标准化授权流时，请使用 OAuth。

两种选择都不是自动安全的。API 密钥需要受保护的存储和限制。OAuth 需要正确的端点验证、重定向处理、令牌验证、范围设计和客户端类型决策。

OAuth 和 OpenID Connect

OAuth 授权访问资源。它没有定义客户端可以视为用户登录身份的标准声明。OpenID Connect 在 OAuth 的基础上添加了身份验证层，并引入了 ID 令牌，这是关于身份验证事件和主题的签名声明。

客户端不应将任意 OAuth 访问令牌视为登录证明。对于登录，请使用 OpenID Connect 流，并根据提供者元数据和配置文件验证 ID 令牌，包括颁发者、受众、签名、时间声明、使用时的随机数，以及授权响应绑定。

当前 OAuth 安全指导

RFC 9700 提供 OAuth 2.0 安全最佳实践基于攻击和实施经验更新部署指导。新系统应使用带有PKCE的授权代码流、精确的重定向URI匹配、安全的浏览器交互和受保护的令牌传输。

隐式授权通过授权响应暴露访问令牌，并不是新客户端的首选设计。资源拥有者密码凭证授权要求客户端处理用户的密码，不应使用。这些较旧的模式可能会出现在遗留系统中，但将它们复制到新实现中会丢弃更强的边界。

常见的OAuth错误

• 调用OAuth身份验证。 OAuth授权API访问；使用OpenID Connect作为标准登录身份层。
• 松散的重定向URI匹配。 仅接受在配置文件规则下精确注册的重定向URI。
• 跳过状态验证。 将响应绑定到发起的浏览器会话，并拒绝不匹配。
• 省略PKCE。 授权代码客户端应为每个请求使用新的验证器和安全挑战。
• 接受任何签名令牌。 资源服务器必须验证发行者、受众、类型或配置文件、时间、签名和授权声明。
• 过于广泛的作用域。 请求并发出最小有用权限。
• 将令牌放入URLs中。 使用HTTPS上的授权头以减少通过日志和浏览器表面的泄露。

OAuth用例

实施清单

1. 选择适合客户端和用例的授权。 交互式用户委托和服务访问具有不同的信任边界。
2. 注册精确的重定向URI。 分开环境并避免开放重定向器。
3. 使用带有PKCE的授权代码。 为每个授权请求生成新的验证器和状态值。
4. 验证每个响应。 检查状态、发行者元数据（如适用）、代码绑定和令牌响应字段。
5. 保护令牌。 将其排除在URLs和日志之外，存储为最短必要时间，并使用安全的浏览器或服务器存储模式。
6. 在资源服务器上强制执行。 验证令牌配置文件、发行者、受众、过期时间、作用域和资源级策略。
7. 计划撤销和事件处理。 用户和管理员需要一种方法来删除授权并禁用被泄露的凭证。

结论

OAuth将用户或服务的主凭证与客户端在API中使用的有限令牌分开。它的角色、授权、范围和端点创建一个标准授权边界，但协议仍然依赖于精确实施。带有PKCE的授权代码、精确的重定向、狭窄发行的令牌、正确的资源服务器验证以及用于登录的OpenID Connect为当前系统提供了坚实的基础。