API 认证

Downcity 现在只保留一种对外认证模型：

• 不再提供用户名 + 密码登录
• 不再提供浏览器 session
• 统一使用 Bearer Token
• token 只由本机终端里的 CLI 管理

当前已经落地的接口是：

• GET /api/auth/status
• GET /api/auth/me
• GET /api/auth/token/list
• POST /api/auth/token/create
• POST /api/auth/token/delete

Token 归属

Token 由拥有本地 runtime 的同一台机器创建和保存。Token 名称只用于人工识别和管理，不代表不同权限或不同渠道类型。

用 Token 调用接口

拿到 token 后，统一放进 Authorization 头：

如果 token 有效，接口会返回当前主体、角色和权限。

管理 Token

Token 创建、列出和删除都是本机操作。HTTP token 管理接口需要先持有 Bearer Token，所以外部调用者不能在没有权限的情况下静默签发新权限。

DC_AUTH_TOKEN

先说结论：

• 只有对外 HTTP 调用才需要 Bearer Token
• 本地托管命令现在默认也是通过本地 agent daemon 的 HTTP 端点访问

对于直接调用 API 的用户，只需要记住一条：

• 对外调用统一使用 Authorization: Bearer <token>

但在 CLI/runtime 里，真正需要关心的环境变量只有一个：

只有当前 HTTP 端点需要鉴权时，CLI 才会进入下面的 token 解析顺序：

1. --token
2. DC_AUTH_TOKEN

所以：

• DC_AUTH_TOKEN 是显式覆盖
• 受保护的 HTTP 调用最终会把 DC_AUTH_TOKEN 归一化为 Bearer Token 请求头

如果你看到 Missing bearer token：

• 不要先怀疑 sessionId
• 先确认目标 HTTP 端点当前是不是启用了鉴权
• 再检查当前进程有没有可用 token 来源
• 如果是在 agent/Bash/ACP 子进程里，先确认这条命令是否需要显式传入 token

具体 token 工作流放在 Downcity CLI 产品文档。

当前边界

当前模型就是 token-only：

• 已移除用户名 + 密码登录
• 已移除 bootstrap-admin
• 已移除 login
• 已移除 password/update
• Console UI、Chrome Extension、外部脚本统一使用显式签发的 Bearer Token

后续如果增加新的接入面，也会继续沿用这套 Bearer Token 模型，而不是再引入单独的登录 session。