设备码授权概览
本文说明什么是设备码授权。
如果你需要进一步了解如何用 CloudBase CLI 与参考实现完成具体对接,请继续阅读 企业自建设备码授权服务对接 CloudBase CLI。
1. 为什么要用设备码授权
设备码授权解决的核心问题是:发起登录请求的终端,与完成网页登录确认的浏览器,往往不在同一台机器,也不在同一个交互界面里。
典型场景包括:
- 用户在远程服务器、跳板机、容器或云端开发机里发起 CloudBase 登录,但浏览器在本地电脑上。
- 用户通过聊天工具或类 OpenClaw 的对话式 AI 工具触发 CloudBase 登录,请求是由机器人或远端执行器发起的,浏览器确认却发生在用户自己的设备上。
这类场景下,传统“终端直接拉起浏览器并等待回调”的登录方式往往不可用。设备码授权把流程拆成两段:
- 终端先申请一组
device_code和user_code。 - 用户再去浏览器里确认“是否允许这次 CloudBase 登录”。
这样做的价值在于:
- 终端侧只负责发起请求和轮询结果,不要求能完成浏览器回调。
- 浏览器侧只负责身份认证和授权确认,不要求和使用 CLI/MCP 发起 CloudBase 登录的客户端在同一个进程或同一台机器上。
- 同一套流程既能支持普通终端,也能支持聊天工具、代理执行器、远程任务这类异步交互场景。
2. 协议约定
一套设备码授权服务通常需要实现 3 个核心接口:
| 接口 | 方法 | 作用 |
|---|---|---|
/auth/device/code | POST | 终端申请设备码,获取 device_code、user_code、verification_uri |
/auth/device/verify | POST | 浏览器侧确认授权,把设备码状态从 pending 更新为 authorized |
/auth/token | POST | 负责首次换取凭证、刷新凭证、撤销会话 |
其中 /auth/token 通过 grant_type 区分 3 种动作:
grant_type | 作用 |
|---|---|
urn:ietf:params:oauth:grant-type:device_code | 使用 device_code 首次换取凭证 |
refresh_token | 使用 refreshToken 刷新临时凭证,并轮换新的 refreshToken |
revoke_token | 撤销 refreshToken 对应会话,供 tcb logout 使用 |
2.1 核心请求与响应
POST /auth/device/code
请求:
{
"client_id": "cloudbase-cli"
}
成功响应:
{
"device_code": "GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS8A",
"user_code": "QWER-ASDF",
"verification_uri": "https://auth.example.com/cli-auth",
"expires_in": 600,
"interval": 3
}
POST /auth/device/verify
这是浏览器侧接口,路径可以由企业自行设计,但职责必须一致:
- 校验当前用户已经完成企业身份认证。
- 接收
user_code。 - 找到对应的
device_code记录。 - 把授权状态从
pending更新为authorized