feat(auth): 支持 CAS / JWT 企业统一认证接入

[MisonL]

提交前必读（请勿删除本节）

• 文档：https://docs.newapi.ai/
• 使用问题先看或先问：https://deepwiki.com/QuantumNous/new-api
• 警告：删除本模板、删除小节标题或随意清空内容的 issue，可能会被直接关闭；重复恶意提交者可能会被 block。

您当前的 newapi 版本

v0.11.6-patch.1

提交确认

• 我已确认目前没有类似 issue
• 我已完整查看过文档 https://docs.newapi.ai/ 和项目 README，已确定现有版本无法满足需求
• 我未删除此模板中的任何引导内容或小节标题，并会按要求完整填写
• 我理解项目维护者精力有限，不遵循模板要求的 issue 可能会被无视或直接关闭

功能描述

希望支持 CAS / JWT 方式接入企业统一身份认证。

当前 new-api 已支持 GitHub / Discord / LinuxDO / OIDC / 自定义 OAuth Provider，但对于很多企业内网环境，实际使用的仍然是 CAS（Central Authentication Service）或“由统一认证网关签发 JWT，再由业务系统验签登录”的模式。

这类环境下，现有 OIDC/OAuth 方案并不总是可用：

1. 认证中心只有 CAS 协议，没有标准 OIDC Discovery
2. 登录后由上游网关直接回传 JWT / Header，不走 OAuth code exchange
3. 企业已有统一认证体系，不希望为 new-api 额外再搭一层 OIDC 兼容代理

希望能支持以下任一形式即可：

1. CAS 登录接入

   • 支持配置 CAS Server 地址
   • 支持 ticket 校验
   • 支持从 CAS 返回的用户属性中映射 username / email / group / role

2. JWT 直连接入

   • 支持配置 JWKS URL 或公钥
   • 支持验签 JWT 后直接完成登录
   • 支持 claim 映射，例如 sub / preferred_username / email / roles / groups

3. 反向代理 Header 信任模式（可选）

   • 例如由上游认证网关完成登录后，把用户信息通过 Header 传给 new-api
   • new-api 在显式开启配置的前提下信任该 Header，并完成用户识别 / 自动注册 / 用户组合并

我理解这三种方式复杂度不同。如果短期不考虑完整 CAS 流程，哪怕先支持“JWT 验签登录”或“可信反代 Header 登录”也会很有价值。

如果需要，我很乐意按维护者偏好的方向贡献代码实现。

应用场景

1. 企业内网统一认证

   • 现有系统已经使用 CAS / SSO / JWT 网关，接入 new-api 时希望复用同一套认证体系

2. 减少用户重复注册

   • 员工通过统一身份登录后，自动进入 new-api，不再额外维护一套本地账号密码

3. 用户组 / 权限自动同步

   • 希望根据外部身份系统返回的部门、角色、组信息映射到 new-api 的用户组或管理员角色

4. 便于自建企业版本落地

   • 对很多企业用户来说，统一认证接入是基础能力，尤其是在内网、校园网、政企环境中

如果维护者认可这个方向，我愿意继续跟进：

• 先补一个最小可用方案设计
• 再按讨论结果提 PR

[new-api-reviewer-bot]

[Bot Review]

感谢提交，这个 issue 基本符合功能请求模板，版本、提交确认、功能描述和应用场景都已填写完整。若后续方便，可以再补充一个你更希望优先落地的最小方案（CAS / JWT / Header 其一）以及期望的配置示例，便于进一步聚焦讨论范围。

[MisonL]

感谢提醒，我补充一下我更希望优先落地的最小方案，便于聚焦讨论范围。

我个人最希望优先支持的是：JWT 直连接入。

原因是这条路径相比完整 CAS 流程改动面更可控，也能覆盖很多企业统一认证场景：

1. 很多企业网关已经能在登录后签发 JWT
2. 对 new-api 来说，只需要做验签、claim 映射、用户查找 / 自动注册
3. 后续如果要扩展到 CAS，也可以把 JWT / claim 映射这一层复用掉

我理解的一个 MVP 形态大概可以是：

1. 管理端新增一种认证方式，例如 JWT SSO
2. 支持以下配置项：
   • issuer
   • audience
   • jwks_url 或 public_key
   • username_claim
   • email_claim
   • group_claim
   • role_claim
   • auto_register
   • auto_merge_by_email
3. 登录流程上支持两种入口：
   • 前端跳转回来时携带 JWT（例如 query / fragment / callback）
   • 或由上游反向代理通过显式配置的 Header 传递 JWT
4. 验签通过后：
   • 先按 sub / 外部用户 ID 查找绑定用户
   • 找不到时按配置决定是否自动注册
   • 可选按 email 自动合并已有用户
   • 再按 group_claim / role_claim 映射用户组或管理员角色

一个比较粗的配置示例可以是：

{
  "enabled": true,
  "issuer": "https://sso.example.com",
  "audience": "new-api",
  "jwks_url": "https://sso.example.com/.well-known/jwks.json",
  "jwt_header": "X-Auth-JWT",
  "username_claim": "preferred_username",
  "email_claim": "email",
  "group_claim": "groups",
  "role_claim": "roles",
  "external_id_claim": "sub",
  "auto_register": true,
  "auto_merge_by_email": true
}

如果维护者觉得 Header 信任模式 更容易先落地，我也接受先做那个版本；但如果只能先选一个方向，我更倾向于先做 JWT 验签登录。

如果这个方向可接受，我很乐意继续整理一个更具体的设计草案，或者直接贡献 PR。

[6639835]

两个AI仙家对话