OAuth 2.0 流程与令牌类型

OAuth 2.0 定义了四种角色。资源所有者是拥有数据的用户（例如拥有 Google Drive 文件的用户）。客户端是请求访问权限的应用程序。授权服务器负责签发访问令牌（例如 Google 的 OAuth 服务器）。资源服务器托管受保护的数据（例如 Google Drive API）。理解这些角色有助于明确每个流程的用途。

授权码流程是服务器端网页应用的正确流程。用户在授权服务器上完成身份验证，授权服务器随后将用户重定向到客户端，并附带一个短期有效的授权码。客户端服务器通过后端通道请求使用此代码交换令牌。令牌不会经过浏览器，从而避免令牌通过浏览器历史记录和引用来源泄露。

隐式流程最初是为仅在浏览器中运行、无法安全存储客户端密钥的 JavaScript 应用设计的。令牌会直接放在 URL 片段中返回，从而绕过后端通道。OAuth 2.1 已弃用隐式流程，因为 PKCE（RFC 7636）允许公共客户端在没有客户端密钥的情况下安全地使用授权码流程。

ROPC 流程允许客户端直接收集用户的用户名和密码，并用它们交换令牌。该流程原本 intended for 高度信任的第一方客户端，但从根本上违背了 OAuth 防止应用程序获取用户凭据的目的。OAuth 2.1 已弃用此流程，任何新应用都不应使用它。

客户端凭据流程用于机器对机器（M2M）身份验证，此时不涉及用户。客户端使用自己的客户端 ID 和密钥直接向授权服务器进行身份验证，并获取供自身使用的访问令牌。常见用途包括：后台任务、微服务之间的通信，以及 API 网关访问后端服务。

设备授权流程（RFC 8628）支持在输入能力有限的设备上使用 OAuth，例如智能电视、游戏主机、打印机和 IoT 设备。设备会显示一个短代码和 URL。用户在手机或计算机上访问该 URL 进行授权。设备会持续轮询授权服务器，直到用户完成授权。

OAuth 2.0 定义了两种访问令牌类型。不透明令牌是随机字符串，资源服务器通过调用授权服务器的令牌自省端点来验证它们。JWT 访问令牌是自包含的：资源服务器可以通过验证签名在本地验证它们，从而减少对自省 API 的调用，但也需要进行密钥管理。

刷新令牌是长期有效的凭据，用于在访问令牌过期后获取新的访问令牌。刷新令牌轮换（OAuth 2.1 要求公共客户端使用）会在每次使用时签发新的刷新令牌，并使旧令牌失效。如果有人使用被盗的刷新令牌，合法客户端会检测到令牌失效，从而能够发现令牌被盗。

RFC 7662 定义了令牌自省端点，资源服务器可以通过该端点向授权服务器查询不透明访问令牌的当前状态（有效/无效）、作用域、主体和过期时间。自省支持实时令牌撤销：一旦令牌在授权服务器上被撤销，自省调用就会立即返回 active: false。

RFC 7009 定义了令牌撤销端点，允许客户端通知授权服务器某个令牌（访问令牌或刷新令牌）应当失效。用户注销或客户端检测到可疑活动时，都会使用此功能。如果没有撤销列表，就无法完全撤销 JWT 访问令牌，因为资源服务器会在本地验证它们，而不会联系授权服务器。

OAuth 2.0 作用域定义了客户端请求的具体权限。授权服务器会将所请求的作用域呈现给用户审批。资源服务器会针对每个端点强制执行作用域要求。应当遵循最小权限原则：客户端只应请求完成任务所需的最少作用域，资源服务器则应拒绝作用域不足的请求。

对于需要验证用户身份、但没有浏览器或键盘的 CLI 工具或 IoT 设备，哪种 OAuth 2.0 流程最合适？

服务器端应用应使用授权码流程。隐式流程已弃用（请改用 PKCE）。ROPC 流程已弃用（它违背了 OAuth 的设计目的）。客户端凭据流程用于 M2M。设备授权流程适用于输入受限的设备。访问令牌可以是不透明令牌或 JWT。刷新令牌应当进行轮换。自省（RFC 7662）和撤销（RFC 7009）共同完善了令牌管理。