第一次尝试在酒店电视上登录 Netflix 时，我差点放弃了。遥控器只有四个方向键和一个数字键盘。我的密码是 18 个字符，还带符号。设计登录界面的人要么自己没用过，要么就是故意设计成这样。角色。
几年后，同样的电视机开始出现变化。它们会显示一个短代码和一个网址。我打开手机，输入网址，输入代码，就登录了。无需遥控器，也无需密码。电视。
这就是 OAuth 2.0 设备授权。大多数人简称它为设备流程。
如果我们运行过 AWS SSO 登录、GitHub 身份验证登录，或者在 Xbox 上登录过 Spotify，那么我们已经使用过它了。如果您正在为 CLI、物联网设备、智能电视应用或其他任何输入密码非常麻烦或不安全的应用构建后端，那么我们最终应该尽早实现它。稍后。
以下是逐步说明 …
步骤1：假设我们正在构建一个名为mycli的命令行界面（CLI）。用户运行：
$ mycli login
以下内容将在幕后进行。
步骤 1：CLI 请求输入代码
CLI 向授权服务器发送 POST 请求：
POST /oauth/device_authorization HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
client_id=mycli-prod&scope=read:repos%20write:repos
服务器响应的内容大致如下： …
{
“device_code”: “GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS”,
“user_code”: “WDJB-MJHT”,
“verification_uri”: “https://example.com/device”,
“verification_uri_complete”: “https://example.com/device?user_code=WDJB-
MJHT”,
“expires_in”: 1800,
“interval”: 5
}
五个领域至关重要：
• device_code 是一个很长的、不透明的字符串。CLI 会将其保密。
• user_code 是简短易懂的版本。CLI 会在屏幕上显示此版本。
• … verification_uri 用户在此处输入代码。
• expires_in指的是兑换的有效时长。通常为 15 至 30 分钟。
• interval 这是 CLI 轮询令牌的频率。我们稍后会详细介绍。
步骤 2：CLI 告诉用户该做什么
你的命令行界面会打印类似这样的内容：
Open this URL in your browser:
https://example.com/device
Enter this code:
WDJB-MJHT
Waiting for confirmation…
用户打开手机或笔记本电脑，打开网址，输入验证码，然后像往常一样使用单点登录 (SSO) 登录并批准请求。
步骤 3：CLI 轮询令牌端点
当我们使用手机时，命令行界面 (CLI) 会一直处于循环状态，每隔五秒钟尝试连接服务器并获取状态。
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=GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS
&client_id=mycli-prod
服务器的响应是五个关键点之一，也是我们大多数人在第一次实现时最容易出错的部分。
我们应该处理的五项回应
Authorization_pending – 用户尚未获得批准 …
slow_down 轮询频率过高。RFC 规定，轮询间隔必须至少增加 5 秒。
expired_token – 交易所超时，停止轮询
access_denied 用户点击了“否”或关闭了页面。停止投票
success – 令牌位于响应体中，就像普通的 OAuth 响应一样： …
{
“access_token”: “eyJhbGciOi…”,
“token_type”: “Bearer”,
“expires_in”: 3600,
“refresh_token”: “v1.MRn7…”,
“scope”: “read:repos write:repos”
}
这就是整个协议。如果我们能处理这五种情况，就能拥有一个可用的设备流客户端。
还有一些其他事情需要处理。
1. 治疗 user_code 就像是秘密一样。 不是的。用户需要手动输入密码。你的任务是让密码足够短，便于阅读，但又难以猜测。标准密码是 8 到 9 个字母数字字符，并去掉容易混淆的字符（例如 0、O、I、1）。GitHub 使用的是 8 个字符，格式为 XXXX XXXX。这是一个很好的例子。模板。
2. 验证页面无速率限制。 用户输入的端点 user_code 这是一个暴力破解的目标。使用精简字母表中的 9 位字符代码，理论上熵值很高，但任何时刻待处理的代码数量都可能达到数千个。务必采取安全措施。按 IP 地址、按会话进行限制，并在尝试后采用指数退避策略。失败。
3. 忽略 slow_down. 我见过一些客户端无论服务器如何设置，都会一直以相同的时间间隔休眠。这在开发环境中没问题，但在生产环境中会被标记为异常。虐待。
4. 未过期 user_code 立即使用。 用户提交验证码后，立即将其标记为已使用。务必以原子方式执行此操作。如果你的勾选后标记逻辑不是事务性的，那么你这里就存在一个潜在的 bug。发生。
5. 将其与 PKCE 混淆。 设备流适用于输入受限的设备。PKCE 适用于无法保存密钥的公共客户端（移动应用、单页应用）。它们表面上看起来很相似（都不需要客户端密钥），但解决的问题却不同。有时你需要同时使用两者。设备流 + PKCE 的组合使用效果很好，而且越来越受欢迎。常见。
结论
设备流协议在 RFC 文档中看起来很复杂，但实际上却可以用一张餐巾纸概括。它只有两个端点，五种响应情况。一旦你构建过一次，你就会纳闷为什么以前有人还要费劲地设置密码。电视机。 …
如果你今天发布的是命令行界面 (CLI)，却仍然要求用户将个人访问令牌粘贴到提示符中，那就帮他们一个忙吧。花一个下午的时间实现这个功能。你的用户将会……注意。
暂无评论内容