作为后端开发者，当团队引入企业级身份管理时，往往面临一个抉择：选择Keycloak 还是 ZITADEL？这个选择不仅影响项目的权限控制架构，还直接关系到系统性能、运维成本和后期扩展难度。

一句话抓住区别

• Keycloak：把权限管理的所有决策都收在自己手里，像一个”全能管家”
• ZITADEL：只负责”你是谁”，”你能干什么”的具体规则交给应用自己做，像一个”聪慧的门卫”

这个哲学差异，决定了两个产品的所有特性。

核心功能对标

Keycloak vs ZITADEL 功能评分对比（0-10分）：

解读：

Keycloak 在权限管理上得分更高（9 分），有完整的资源、策略、权限三层体系。但 ZITADEL 在性能和易用性上胜出，由于不需要频繁查询 IAM 系统。

两条授权路线

Keycloak：每次操作都要”请示”

用户点击"删除按钮"
        ↓
应用向 Keycloak 发起授权查询
"用户 Alice 能否删除文章 123？"
        ↓
Keycloak 查阅：
  - 用户角色：Editor
  - 文章资源定义：需要 Editor 或 Admin
  - 时间策略：工作时间才允许
  - IP 策略：必须公司网络
        ↓
Keycloak 返回：Allow ✅
        ↓
应用执行删除（耗时 200ms）

代价： 每次权限判断都是一次网络往返，高延迟。

ZITADEL：权限写在”身份证”上

用户登录 ZITADEL
        ↓
ZITADEL 运行 Actions 脚本
提取用户角色 + 元数据
生成权限列表：
{
  "roles": ["editor"],
  "permissions": ["article:view", "article:edit"],
  "experience_level": "senior"
}
        ↓
生成 JWT Token，包含上述信息
        ↓
用户点击"删除按钮"
        ↓
应用**本地**解析 Token
发现用户是 editor，有 article:delete 权限
        ↓
直接执行删除（耗时 50ms）
text

优势： Token 自包含，秒级响应，无网络往返。

实战对比：7 个常见场景

代码对比：React + Spring Boot

Keycloak 方案（频繁询问）

后端 Spring Boot：

@GetMapping("/articles/{id}")
public Article getArticle(@PathVariable String id) {
    // 每次请求都要向 Keycloak 查询一次权限
    AuthorizationResponse authz = keycloak.authorize(
        new AuthorizationRequest()
            .resource("article")
            .scopes(asList("view"))
            .permission("article:" + id)
    );
    
    if (authz.isGranted()) {
        return articleService.getById(id);
    }
    throw new ForbiddenException("无权限");
}

前端 React：

const [canEdit, setCanEdit] = useState(false);

useEffect(() => {
    // 每次组件加载都要查询一次
    keycloak.authorization.entitlements('articles')
        .then(perms => setCanEdit(perms.includes('edit')));
}, [articleId]);

return <button disabled={!canEdit}>编辑</button>;

ZITADEL 方案（一次解析）

后端 Spring Boot：

@PreAuthorize("hasRole('editor')")  // 直接从 Token 读取
@PutMapping("/articles/{id}")
public Article updateArticle(@PathVariable String id) {
    return articleService.update(id);
}

前端 React：

import jwtDecode from 'jwt-decode';

const { roles, permissions } = jwtDecode(accessToken);

return (
    <button disabled={!roles.includes('editor')}>
        编辑
    </button>
);

代码行数对比：

• Keycloak：40+ 行（多个异步调用）
• ZITADEL：10+ 行（同步解析）

为什么 ZITADEL 不包办权限管理？

ZITADEL 的创始人曾在 GitHub issue 上这样说：

“我们信任身份和授权应该分离。就像操作系统一样，内核负责进程管理（身份），但文件权限由文件系统决定（授权）。ZITADEL 专注于核心，让应用或专业授权引擎处理复杂规则。”

这反映了云原生时代的新思路：

• ✅ 单一职责：每个组件只做一件事，做到极致
• ✅ 模块化：需要复杂授权时，插入 OpenFGA/Cerbos，而不是内置
• ✅ 高性能：Token 即”能力证明”，无需实时查询

选型决策树

选 Keycloak 如果你…

✅ 权限规则复杂（>20 种角色权限组合）
✅ 多个独立应用需要统一权限体系
✅ 需要时间/IP/属性等复杂策略
✅ 审计合规要求高（金融、医疗）
✅ 团队已有 Keycloak 运维经验
✅ 需要权限规则实时更新不影响在线用户

典型场景： 大型企业、多租户 SaaS、政府系统

选 ZITADEL 如果你…

✅ 系统追求低延迟（<100ms）
✅ 微服务/Serverless 架构
✅ 权限规则相对简单且稳定（<5 种基础角色）
✅ 初创团队，快速迭代
✅ 想用 OpenFGA/Cerbos 处理复杂授权
✅ 云原生友善（Kubernetes、gRPC）

典型场景： 初创公司、高并发 API 服务、微服务中台

性能与成本对比

响应时间（1 万并发）

年度成本估算（每 100 万用户）

结论： ZITADEL 的性能优势在大规模场景下能节省 50%+ 的成本。

迁移路径

从 Keycloak 迁移到 ZITADEL

第一步：能直接迁的

• ✅ 用户和组织结构（数据导出）
• ✅ 基础 RBAC 角色映射

第二步：需要重新设计的

• ❌ Authorization Services（资源、策略、权限）
• ❌ Policy 规则脚本

第三步：推荐方案

ZITADEL (身份管理)
    ↓
Actions 脚本 (基础权限提取)
    ↓
应用代码 (权限决策)
    ↓
[可选] OpenFGA (复杂关系型授权)

社区与生态

最终提议

快速决策表

是否微服务架构？
├─ 是 → ZITADEL ✅
└─ 否 → 继续下一题

系统是否需要 <100ms 响应？
├─ 是 → ZITADEL ✅
└─ 否 → 继续下一题

权限规则是否超过 10 种？
├─ 是 → Keycloak ✅
└─ 否 → 继续下一题

是否需要实时权限变更？
├─ 是 → Keycloak ✅
└─ 否 → ZITADEL ✅

我的提议

第一次做身份管理
→ 选 ZITADEL，快速验证，3 天上线

企业级系统
→ 选 Keycloak，成熟稳定，审计友善

要求都很高
→ 混合方案：ZITADEL + OpenFGA
这是目前最先进的架构

一句话总结

Keycloak 是”大管家”，什么都管，但配置复杂；ZITADEL 是”聪慧的门卫”，只管身份验证，让应用自己决定权限。

选错了？高并发项目用 Keycloak 会成为性能瓶颈，权限复杂的项目用 ZITADEL 会陷入代码混乱。

你的项目选了谁？在评论区分享你的故事吧！

参考资源

• ZITADEL 官方文档：https://zitadel.com/docs
• Keycloak 官方文档：https://www.keycloak.org/documentation
• ZITADEL 细粒度授权示例：https://github.com/zitadel/example-fine-grained-authorization
• OpenFGA—推荐与 ZITADEL 配合：https://openfga.dev/