iOS Developer的全栈之路 - Keycloak(1)

在创建项目初期，每个项目的必经之路就是构建用户系统，实现注册，登录，忘记密码，三方登录等一系列功能，尤其当在如今微服务盛行的时代，SSO也成了一个必不可少的核心功能。时间、精力大把的投入，有时依然会出现安全漏洞，性能瓶颈等等问题。而Keycloak就是为此而生。

本文将介绍一下Keycloak的全景图，使用方式将在之后的文章中进行说明。

看一下RedHat官方对它的定义

Open Source Identity and Access Management for Modern Applications and Services. Add authentication to applications and secure services with minimum fuss. No need to deal with storing users or authenticating users. It's all available out of the box. You'll even get advanced features such as User Federation, Identity Brokering and Social Login.

提取一下重点，RedHat背书，开源的集中式用户认证授权管理系统。这个项目起自2013年，到2015被广泛使用，每6周一次迭代，目前最新的版本为8.0.1。项目的健壮性，安全性，可扩展性都相当完善。

这里总结一下它的核心亮点：

1. Single Sign-On 和 Single Sign-Out
2. 灵活的认证和授权机制
3. 实现了多种标准协议：OAuth 2，OIDC 1.0，SAML 2.0， Docker Auth
4. Multi-Factor Authentication，如 One time password
5. 三方登录，Google，Facebook，Twitter等，同时也提供了扩展接口，网上也有人提供了对微信登录的实现
6. 集中式的用户管理
7. 提供了与遗留用户系统的集成接口
8. 开箱即用，提供了基于UI，Restful接口以及Command Line的配置方式

核心概念

我们来通过一张图，了解一下它的核心概念

keycloak core concept.png

1. Users：就不用多说了，用户管理系统嘛
2. Clients：这里的Clients指的的是被keycloak保护的应用，比如说SSO中，的一个server，一个用户来访问这个server，如果请求中没有认证信息，将被redirect到keycloak，登录成功后再返回原server。
3. Roles：对用户的权限管理，添加角色
4. Identity-Provider：提供了三方登录的方式，或是其他可以提供OICD等协议的用户系统
5. User Federation：提供对接遗留系统的接口
6. Thems：keycloak提供了一组的用户登录界面，同时也支持自定义该界面

技术栈及架构图

下图展示了keycloak用到的一些核心技术栈

keycloak tech stack.png

下图展示了Keycloak的架构简图，其中，对外暴露了5个HTTP Endpoint，分别用于的管理员的操作，查看内部信息，用户登录注册，ODIC和SAML的接口。同时在最右侧，Keycloak支持水平扩展，同时共享session，用户信息，以及相关的配置信息

architecture.png

SSO 登录流程

接下来我们一起来看一看采用Keycloak之后的登录授权流程是怎样的，图中App指的的是一个没有前后端分离的App。

login 1.png

1. 用户未登录状态下访问App
2. App将用户redirect到Keycloak
   2a. 用户通过用户名密码，或是三方登录的方式进行认证
   2b. Keycloak验证用户合法性
3. Keycloak创建SSO session cookie并跳转回App，redirect url中带有code
4. App使用code和Keycloak换取Token
5. App验证Token并把它关联在一个session中
   5a. 此时用户便在App中登录了。

当用户再访问同在一个SSO系统中的另一个App时，用户就不用再次输入用户密码了，流程如下图所示：

login 2.png

6. 用户访问另一个App
7. App将用redirect到Keycloak
8. 此时Keycloak检测到了这个已经登录的session，同时创建一个code，跳转回这个App
9. App使用code和Keycloak换取Token
10. App验证Token并把它关联在一个session中
    10a. 此时用户在这个App中也是登录状态了

其中跳转的过程，用户是无感知的只是一个类似的loading状态。而上述的token通常是一个JWT，那么在前后端分离的项目中呢？访问流程如下图所示，图中的App可以认为是一个前后端分离的web，而用户已经在这个app中登录了：

login 3.png

1. 用户访问已登录的App
2. App需要发请求到后端获取数据，request的header中带有JWT
3. Backend在JWT中获取Kid的值，再看看自己对于的public key知否有效
   3a. 假设已经失效，或是就没有，Backend向Keycloak获取该public key
   3b. Keycloak将public key返回给Backend
4. 有了这个public key，Backend验证JWT的合法性，如何合法，就处理这个请求。

以上便是Keycloak的核心概念，及工作流程，有了这个认知，再来使用Keycloak时便心中有数了，下一节中，我会将Keycloak集成到之前的项目中。