当我们谈论 OAuth 2.0 授权协议时，大多数开发者首先想到的是授权码模式（Authorization Code Grant）或隐式授权模式（Implicit Grant）。这些流程假设用户能够在浏览器中完成身份验证，并且客户端应用能够接收来自授权服务器的重定向回调。然而，在物联网（IoT）领域，大量设备并不具备传统意义上的浏览器交互能力 —— 智能电视无法输入复杂凭证、工业传感器缺乏键盘、嵌入式设备难以维护长连接。RFC 8628 正是为解决这一类场景而诞生的技术规范，它定义了一种名为 “设备授权授予”（Device Authorization Grant）的协议扩展，允许受限设备通过用户辅助的方式完成 OAuth 授权流程。
协议设计背景与核心约束
RFC 8628 的设计目标明确针对两类受限设备：一是缺乏合适浏览器以进行传统用户代理交互的设备，例如智能电视、媒体播放器、数字相框和打印机；二是输入能力受限到无法在授权过程中输入文本进行身份验证的设备。这一协议并非要取代智能手机等能力完善设备上的浏览器 OAuth 流程，而是作为一种补充方案，服务于那些在硬件和交互设计上无法承载完整 Web 体验的场景。
使用该协议需要满足四个基本前置条件：设备已接入互联网、设备能够发起 outbound HTTPS 请求、设备能够向用户展示 URI 和验证码、用户拥有可用于处理授权请求的辅助设备（如智能手机或电脑）。这些约束条件决定了协议的实现架构 —— 设备只需要具备单向通信能力，无需接收来自服务器的回调，这极大地放宽了对网络拓扑的要求，使得设备可以位于 NAT 或防火墙之后，这是许多 IoT 设备的典型部署环境。
协议的核心设计哲学是将身份验证和授权同意的操作从受限设备转移到用户手中的辅助设备上。设备客户端不直接与用户代理（即浏览器）交互，而是指示用户使用另一台设备连接到授权服务器来批准访问请求。由于协议支持无法接收传入请求的客户端，客户端通过轮询授权服务器来获知用户是否已完成授权流程。这种设计在保持 OAuth 2.0 安全模型完整性的同时，成功突破了设备能力的限制。
协议交互流程与关键阶段
设备授权授予协议的完整交互流程包含六个关键步骤，形成了一个涉及设备端、用户端和授权服务器端三方协同的复杂序列。
在初始化阶段，设备客户端向授权服务器的设备授权端点（device authorization endpoint）发起 POST 请求，请求中必须包含client_id参数，可选地包含scope参数以指定请求的权限范围。所有请求必须使用 TLS 协议保护，并遵循 BCP 195 中关于 TLS 最佳实现的建议。授权服务器在收到有效请求后，会生成一组验证代码并返回 JSON 格式的响应，其中包含device_code、user_code、verification_uri、expires_in以及可选的interval参数。device_code是设备在后续轮询中使用的令牌，而user_code是供用户手动输入的短码，verification_uri是用户需要访问的授权页面地址。
用户交互阶段是协议区别于传统 OAuth 流程的关键环节。设备在获得授权响应后，需要将user_code和verification_uri展示给用户，指示用户使用辅助设备上的浏览器访问该 URI 并输入验证码。RFC 8628 特别强调了可用性设计：授权服务器应使用简短、易记的 URI 以降低用户输入负担；user_code的字符集应考虑移动端键盘的输入效率，推荐使用不含数字的大写字母（如 BCDFGHJKLMNPQRSTVWXZ），并可添加分隔符以提高可读性 —— 规范中给出的示例 "WDJB-MJHT" 正是这种设计理念的体现。当verification_uri_complete可用时，设备还可以生成二维码等非文本形式的信息传输方式，用户只需扫描即可直接打开授权页面，无需手动输入任何内容。
设备轮询阶段从用户开始与授权服务器交互时同步启动。设备客户端使用grant_type为urn:ietf:params:oauth:grant-type:device_code的请求向令牌端点（token endpoint）发起轮询，请求中包含device_code和client_id。授权服务器可能返回四种不同的响应状态：当用户尚未完成授权时返回authorization_pending，客户端应等待至少interval指定的秒数（或默认 5 秒）后继续轮询；如果服务器希望客户端降低轮询频率，则返回slow_down并要求客户端将间隔时间增加至少 5 秒；当用户明确拒绝授权时返回access_denied；当device_code超过有效期时返回expired_token。一旦用户完成授权，令牌端点会返回标准的 OAuth 令牌响应，包含access_token、token_type、expires_in以及可选的refresh_token。
与传统 OAuth 2.0 流程的架构差异
从架构层面审视，设备授权授予与传统的授权码模式存在根本性的设计差异。传统授权码流程假设客户端能够启动一个 Web 服务器或使用 localhost 重定向来接收授权服务器的回传请求，这个假设在桌面应用或移动应用中通常成立，但在 IoT 设备上往往无法满足 —— 许多嵌入式系统无法运行 Web 服务器，也无法声明一个可访问的回调 URL。
设备授权授予通过将授权流程拆分为两个并行的执行路径来克服这一限制：受限设备通过轮询机制主动查询授权状态，而用户通过辅助设备完成身份验证和授权确认。这种设计带来的直接优势是设备无需接收任何传入连接，从而能够适应更加严格的网络环境部署。传统流程中的隐式授权（Implicit Grant）虽然也不需要后端回调，但它依赖于浏览器中的 JavaScript 来捕获访问令牌，这在无浏览器或浏览器能力受限的设备上同样不可行。
另一个显著差异体现在错误处理和重试机制上。传统授权码流程一旦用户完成授权就会获得令牌并结束，而设备授权授予需要处理用户可能花费较长时间完成身份验证的情况 —— 用户可能需要先注册账户、配置多因素认证、或在不同设备间切换。因此协议设计了专门的轮询间隔控制机制，客户端不能无限制地高频请求令牌，服务器通过interval参数和slow_down错误码来调控请求频率，避免对令牌端点造成过载压力。这种设计体现了对受限设备网络行为规范的深刻理解。
核心安全机制与技术参数
RFC 8628 在安全机制设计上充分考虑了设备授权场景的特殊性，构建了多层次的安全防护体系。
针对用户码暴力破解风险，协议进行了审慎的参数设计。由于用户码需要手动输入，其长度和复杂度受到可用性的严格约束，无法像设备码那样使用高熵值。规范建议通过结合速率限制和较短的有效期来弥补熵值的不足。以 8 字符的 Base20 用户码为例，其熵值约为 34.5 比特，若限制 5 次尝试次数并配合 1800 秒（约 30 分钟）的有效期，可将随机猜测成功的概率控制在极低水平。授权服务器必须实现对用户码输入的速率限制，这是对抗暴力破解的关键措施。
设备码的安全性要求则截然不同。由于设备码不展示给用户，服务器应使用高熵值的随机字符串以抵御暴力猜测。RFC 8628 明确建议使用至少 128 比特的熵值，确保即使攻击者能够观察到大量授权会话的设备码，也难以通过枚举方式猜测有效的设备码。
协议还特别关注了远程钓鱼攻击的防护场景。攻击者可能诱骗用户在攻击者控制的设备上完成授权流程，从而将授权结果绑定到攻击者的账户。为缓解此类风险，授权服务器应在授权页面明确告知用户正在授权一台设备，并要求用户确认该设备处于自己的控制之下。当用户通过扫描verification_uri_complete二维码启动流程时，规范建议服务器显示设备上展示的验证码，要求用户核对一致性以确认授权目标正确。这种双向确认机制有效降低了钓鱼攻击的成功概率。
在会话劫持防护方面，协议要求设备在展示验证码时考虑可视环境的安全性。由于授权过程中存在时间窗口，恶意用户可能通过观察设备屏幕快速输入验证码并抢先完成授权。设备设计应尽量缩短验证码的可见时间，或在条件允许时使用音频输出等替代展示方式。
IoT 场景适配的工程实践要点
将 RFC 8628 协议实现到具体 IoT 产品中时，开发者需要关注多个工程实践层面的考量。
轮询实现的健壮性是首要关注点。客户端必须严格遵守interval参数的要求，在收到authorization_pending或slow_down响应后等待足够的时间再发起下一次请求。RFC 8628 特别建议在遇到连接超时时，客户端应主动降低轮询频率，例如采用指数退避策略将每次重试的间隔翻倍。这种设计考虑到了网络不稳定场景下的服务端保护。设备端实现还应妥善处理expired_token错误，当设备码过期时应提示用户重新发起授权流程，而非自动重试以避免对服务器的无效请求冲击。
设备凭证管理是另一个关键维度。IoT 设备通常无法安全存储客户端密钥，因此 RFC 8628 将这类设备视为公共客户端（public client），与 RFC 6749 中的定义一致。开发者应认识到静态分发的客户端凭证存在被提取和滥用的风险，在产品设计层面应考虑额外的安全措施 —— 例如设备出厂时的唯一标识绑定、授权服务器端的设备白名单机制、或结合设备证明（device attestation）技术来增强客户端身份的可信度。
离线场景和间歇性连接的处理也需要纳入设计考量。IoT 设备可能面临网络不稳定或间歇性连接的场景，客户端实现应具备在网络恢复后正确恢复轮询的能力，同时妥善处理授权过程中设备重启的情况 —— 通常需要向用户重新展示新的验证码而非恢复之前的会话。
令牌生命周期管理方面，需要注意设备授权授予的典型有效期设置。根据规范建议，expires_in通常设置为 1800 秒（30 分钟），这一时长足以让用户在辅助设备上完成身份验证流程，但开发者应根据具体产品场景考虑是否需要调整。当获得访问令牌后，设备应按照expires_in字段管理令牌的有效性，并在令牌临近过期时使用refresh_token获取新令牌（若服务器支持）。
总结与协议演进视角
RFC 8628 为 OAuth 2.0 授权框架在 IoT 领域的适用性提供了标准化解决方案，其设计充分平衡了安全性、可用性和实现灵活性。通过将用户交互转移到能力更强的辅助设备上，同时保持受限设备的单向通信模式，协议成功突破了传统 OAuth 流程对设备能力的硬性要求。
从协议演进的角度观察，RFC 8628 的制定过程反映了 IETF 对新兴应用场景的持续关注。该规范于 2019 年发布，至今已获得主流身份提供商（包括微软身份平台、谷歌等）的广泛支持，被大量智能电视、游戏主机和 CLI 工具采用。随着 IoT 设备类型的日益丰富和 Edge Computing 场景的兴起，设备授权授予的使用范围预计将持续扩展。
对于安全工程师和 IoT 开发者而言，深入理解 RFC 8628 的协议细节不仅有助于正确实现授权流程，更能够在产品设计阶段就纳入适当的安全考量。协议中的每一个参数 —— 从interval的轮询间隔到user_code的字符集选择，从速率限制策略到用户确认机制 —— 都体现了在受限环境下的安全工程权衡。掌握这些设计原则，是构建既安全又易用的 IoT 授权系统的基础。
参考资料
- RFC 8628 - OAuth 2.0 Device Authorization Grant: https://datatracker.ietf.org/doc/html/rfc8628