认证、Token 与 RBAC 模型
权限只有两层：角色决定能进哪些页面、调哪些接口，业务组成员关系决定能动哪些数据；界面、HTTP API 和 MCP 共用这一套。
夜莺的权限模型只有两层，但很多人只看到其中一层，于是困惑「为什么我是 Admin 还是改不了这条规则」。
两层权限
第一层：角色，决定你能进哪些页面、调哪些接口。
内置三个角色：Admin、Standard、Guest。角色挂在用户身上，一个用户可以有多个角色。
角色由一组「权限点」组成，比如 /alert-rules/add、/metric/explorer。
第二层：业务组成员关系，决定你能操作哪些数据。 用户属于若干团队，团队是业务组的成员并带读写标记。 见业务组。
两层是且的关系：
能改这条告警规则 = 角色里有「改告警规则」这个权限点
且
我所在的某个团队，对这条规则所属的业务组有读写权
Admin 角色跳过第二层。所以「我是 Admin 却改不了」通常意味着你其实是 Standard。
三种认证方式，同一套权限
| 入口 | 怎么认证 | 权限来自 |
|---|---|---|
| 浏览器 | 用户名密码或 SSO，换 JWT | 登录的那个用户 |
| HTTP API | X-User-Token 个人 Token | Token 所属用户 |
| MCP / A2A 客户端 | 同上，或 OAuth Authorization: Bearer | 同上 |
关键一点：Token 没有独立权限。 它就是「以这个用户的身份行动」的凭据， 一点不多、一点不少。
这条规则的实际含义是：给 AI 客户端或者自动化脚本用的 Token， 应该建一个最小权限的专用账号再生成，而不是直接用 root 的。 账号出问题时也能单独吊销，不影响别人。
单点登录
支持 OIDC、OAuth2、LDAP、CAS，以及钉钉、飞书扫码登录。 在 系统配置 → 单点登录 里配。
接了 SSO 之后，用户第一次登录会自动创建，默认角色可以配。 外部的组织架构可以映射成夜莺的角色，具体见 SSO 与外部身份源。
也支持反向代理认证（[HTTP.ProxyAuth]）：由前置网关完成认证，
把用户名放在请求头里传进来。开了这个，JWT 登录就会被禁用——
所以要么全走网关，要么全走夜莺自己的登录。
Token 怎么管
个人 Token 在头像菜单里生成。它长期有效，直到被删除。
生产上值得做的：
- 给每个用途单独一个 Token（这个给 CI、那个给 AI 客户端），出事好定位；
- 人员离职、Token 泄漏时逐个吊销，不用改所有人的凭据；
- 定期轮换，见 Token 与凭据轮换。