4. OAuth2.0 客户端凭证模式与设备授权模式：机器对机器、无浏览器设备认证

在 OAuth2.0 的授权码模式与隐式模式中，资源所有者（用户）必须亲自参与交互。然而，在微服务架构与物联网场景中，存在两类特殊的认证需求：机器对机器（M2M） 的后端通信，以及无浏览器设备（如智能电视、CLI 工具）的授权。本章深入剖析客户端凭证模式（Client Credentials Grant）与设备授权模式（Device Authorization Grant），并结合 Mock 依赖隔离与链路追踪调试，确保这两种模式在分布式系统中的正确实现。

4.1 客户端凭证模式（Client Credentials Grant）

客户端凭证模式适用于客户端自身作为资源所有者，代表应用访问其拥有的受保护资源，无需用户参与。典型场景包括：微服务间的内部 API 调用、定时任务、后台批处理程序。

4.1.1 核心流程与令牌获取

该模式仅需客户端提供其 client_id 和 client_secret 向授权服务器直接请求 access_token。流程极为简洁，不涉及授权码或用户交互。

4.1.2 令牌请求示例

POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=your_client_id
&client_secret=your_client_secret
&scope=read write

4.1.3 Mock 依赖隔离调试策略

在微服务调试中，客户端凭证模式常因网络隔离、凭证泄露或令牌缓存问题导致失败。推荐使用 Mock 授权服务器进行依赖隔离：

• Mock 授权服务器：使用 WireMock 或 MockServer 模拟 /oauth/token 端点，返回固定格式的 JWT 令牌。
• 令牌缓存模拟：在 Mock 中模拟令牌过期逻辑，验证客户端是否正确处理 401 并自动重试。
• 链路追踪注入：在 Mock 响应中注入 trace_id，确保调用链完整。

4.2 设备授权模式（Device Authorization Grant）

设备授权模式专为无浏览器或输入受限的设备设计，如智能电视、打印机、CLI 工具。设备通过用户代理（如手机、电脑）完成授权，而非直接与授权服务器交互。

4.2.1 核心流程与用户交互

该模式包含两个阶段：设备向授权服务器请求设备码和用户码，用户通过浏览器访问验证 URI 并输入用户码完成授权，设备轮询授权服务器获取 access_token。

步骤	参与者	描述
1	设备 → 授权服务器	发起设备授权请求，获取 device_code、user_code、verification_uri
2	用户 → 浏览器	用户访问 verification_uri，输入 user_code 并授权
3	设备 → 授权服务器	设备轮询 /oauth/token，携带 device_code 和 grant_type=device_code
4	授权服务器 → 设备	用户授权成功后，返回 access_token（可选 refresh_token）

4.2.2 设备授权请求与轮询示例

设备授权请求：

POST /oauth/device_authorization HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id
&scope=offline_access

设备轮询令牌：

POST /oauth/token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:device_code
&device_code=GmRhmhcxhwQkSqQx
&client_id=your_client_id

4.2.3 Mock 依赖隔离与轮询调试

设备授权模式的调试难点在于轮询逻辑与用户授权状态的模拟。使用 Mock 服务器可以精确控制授权状态转换：

• 模拟授权状态：Mock 端点初始返回 authorization_pending，在指定次数后返回 success，验证设备轮询退避策略。
• 模拟错误场景：返回 expired_token、slow_down 等错误码，确保客户端正确处理。
• 链路追踪：在 Mock 响应中附加 X-Request-Id，结合 Zipkin 或 Jaeger 追踪轮询调用链。

4.3 两种模式对比与调试要点

维度	客户端凭证模式	设备授权模式
用户参与	无需用户	需要用户通过浏览器授权
适用场景	微服务间通信、后台任务	智能电视、CLI、IoT 设备
令牌获取方式	直接请求，一次完成	轮询，依赖用户授权状态
刷新令牌	通常不支持	可选支持
Mock 调试重点	凭证验证、令牌缓存	轮询状态机、用户授权模拟

4.4 链路追踪集成实践

在分布式系统中，无论使用哪种模式，都需要将 trace_id 和 span_id 注入到令牌请求与 API 调用中。推荐做法：

• 客户端凭证模式：在获取令牌的 HTTP 请求头中添加 X-B3-TraceId，并在后续 API 调用中透传。
• 设备授权模式：在设备轮询请求中携带 trace_id，确保用户授权与令牌获取的调用链可关联。
• Mock 验证：使用 Mock 服务器记录所有请求的 trace_id，通过断言确保链路完整性。