前言

在考虑迁移单体应用到 Go 微服务时,发现身份认证是一个比较棘手的问题。调研了很多网关层面的身份认证解决方案,同时关注了一些开源项目,但是实际部署使用起来总觉得不是那么的顺心,

直到我发现了 ZITADEL。这是一个瑞士的团队基于 Golang 开发的云原生身份认证服务。经过研究和本地部署尝试后,不得不说该项目的完善程度相对较高了,而且是产品化思维主导开发的。无论对于开发者还是最终用户来说用户体验都可以媲美大型商业 IDaaS。例如国内的 Authing。

该项目成立于 2019 年,社区比较活跃,我自己部署和使用后也尝试参与到开源项目中,例如贡献汉化语言包,修复语言切换时的问题等。

功能

  • 身份管理(通过 组织的抽象模式来实现 EIAM 和 CIAM)
  • 支持 RESTful、gRPC
  • SDK
  • 授权管理
  • 项目管理
  • 应用管理
  • 跨组织、项目授权用户
  • Passwordless(FaceID,TouchID 和 Key 等)
  • Multifactor Authentication(FaceID,TouchID,Key 和 OTP 等)
  • 用户自定义元数据
  • 用户身份认证流程

概念

Instance

在 ZITADEL 中 Instance 的抽象层最高,可以理解成多租户的模型,例如每个公司可以是一个 Instance。在 Instance 中可以可以管理多个组织,同时也可以设置外部 IDP,密码复杂度,用户锁定策略,Passwordless 和 MFA 策略。

Instance 管理

Organizations

组织是对用户的一层抽象,用于管理和区分用户作用范围,例如对于企业来说,可能有 B 端客户和 C 端客户,那么可以将这些用户放在不同的组织中,同时自己内部系统的认证和授权再另外创建一个独立的组织。

组织也可以自定义外部 IDP 和品牌化身份认证 UI,以及覆盖 Instance 中的一些安全设置。

Actions and Flows

这部分适用于设置用户身份验证后的触发流程和动作。

动作和流程

Domains

组织的名称是域名中的一部分,而用户登录时需要使用用户名加上域名的方式进行登录,有点想电子邮箱地址。

例如:公司名叫 Betterde,这是一个 Instance,我们再创建一个内部人员 Internal 组织,那么这个组织下的用户登录时的用户名就是 user@internal.betterde.com

User

用户就是我们理解的普通用户,可以在项目中对用户进行授权,如果用户在项目中没有授权,则无法在项目下的应用中通过 OAuth 流程进行登录。

也就是说,即使用户在组织中注册了信息,这时候依然无法登录的,需要管理人员在 Consule UI 中对用户所需要访问的应用进行授权,授权是指授予用户角色。当用户登录后会在 ID Token 中携带用户的在项目中的角色信息,用于后端服务的鉴权。

Service User

用于后端服务之间通信的用户身份验证,例如在跨公司的服务调用时,需要身份验证的话,可以创建一个 Service User。

项目

项目是对应用的抽象,那么为什么需要这样的抽象层呢?在实际的公司项目中,我们往往会将一个项目分为前端和后端,甚至是原生 APP。而这些对于用户来说是一个应用。通过这种方式可以更好的管理用户授权和同一项目不同端的应用。

项目管理

应用

这里的应用就是我们理解的 Web App、Native App 和 Service API,我们可以针对应用的不同类型设置不同的授权方式,以及 Token 的设置。

应用管理

在现有系统中集成

只要系统支持 OIDC 的方式,就能够使用 ZITADEL 作为外部 IDP 进行身份认证,例如 MiniO。

MinIO 集成 ZITADEL

先看一下配置后的效果:

MinIO SSO

ZITADEL Auth

配置信息参考:

OIDC 配置

注意: Claim Name 的配置非常重要,因为 MinIO 与 ZITADEL 存在兼容性问题,所有我们这里不能通过角色来进行授权,只能通过 ZITADEL 的用户 ID,也就是 sub 字段来获取用户信息。同时还要在 MinIO 中为用户创建对应的 IAM Policy 并设置上对应的访问权限。

在 APISIX 中使用 OIDC

APISIX Gateway 是支持 OIDC 的,通过 OIDC 插件可以由 API Gateway 实现集中身份验证,这样对于后端的服务来说,就不需要每个服务中都实现身份验证的逻辑了。后端只需要关注业务逻辑本身,这样降低了开发人员的心智负担!

APISIX 的 OIDC 插件支持两种自省模式:

  • 令牌自省:通过请求 IDaaS 服务的 Introspection Endpoint 来自省,获取用户信息,并将用户信息进行 Base64 编码后附加到 X-Userinfo 请求头中;
  • 公钥自省:APISIX 通过公钥对 Access Token 或 ID Token 进行验签和有效期校验,但是不会将 Token 中包含的信息附加到请求头中,需要后端自行从 Token 中解析。

自省流程如下图所示:

API Gateway 集中身份验证

类似项目

总结

因为感兴趣它的设计和实现,我阅读了 ZITADEL 的源码,他们的技术栈让我眼前一亮,后端采用 gRPC 再通过 gRPC-Gateway 代理支持 RESTFul API 的方式。

前端也是采用 gRPC-Web 的方式与后端交互,这一点让我比较惊讶。这种方式虽然之前在网上看到过,但是因为当时处于 Beta 版。没想到已经有团队应用到生产环境中了!

研读代码后,确实学到了很多,后面考虑在项目中使用同样的技术栈来构建后端服务和通过 Proto 文件生成对应的文档和前后端代码。

I hope this is helpful, Happy hacking…