Keycloak首次在ThoughtWorks技术雷达第16期中以“评估”的状态出现。
技术雷达15期正式提出“安全是每一个人的问题”，同时也对Docker和微服务进行了强调。
在微服务盛行的时代，现代Web服务的拆分对鉴权和授权也提出了新的挑战，而这正是Keycloak解决的问题。
用一句官方语言来解释，“Keycloak为现代应用系统和服务提供开源的鉴权和授权访问控制管理”。
Keycloak实现了OpenID，Auth2.0，SAML单点登录协议，同时提供LDAP和Active Directory，以及OpenID Connect, SAML2.0 IdPs，Github，Google等第三方登录适配功能，能够做到非常简单的开箱即用。但是在实际上，如果想稍微顺利的添加配置，还是需要简单的了解SSO，若想要配置更加复杂的场景，则需要了解对应的协议。
原理概念普及
（图片来自：SAML2.0 wiki）
上图是使用SAML协议时，用户首次登录的一种最常用的工作流（SP Redirect Request; IdP POST Response），也是Keycloak的默认方式（当选择SAML协议时），如果忽视传输内容（SAML基于xml传输，OpenID普通文本）的不同，这种工作流程与OpenID的流程非常相似，可以用它来大致了解登录流程。
用户请求Service Provider（简称SP），通过SessionID判断是否存在已鉴权的Context，否则返回302，重定向至Identity Provider（简称IdP），并携带参数，IdP检测是否已经存在鉴权Context，否则要求用户提供凭证（例如普通的用户名密码输入框），成功后返回302，并将数据返回给SP。
在此流程中，单点登录能够做到的非常关键的一点就是Web中的鉴权Context，这种方式的实现原理也就是利用了Cookie（Web Session的实现），多个SP对应一个IdP，任一台SP登录成功，IdP即有了鉴权Content，随后其他SP即可直接登录，这个过程可简单的观察浏览器地址栏变更或查看浏览器网络请求过程。
另一种方式是针对提供RESTful API的服务，这种情况下必须使用OpenID Connect协议，这种协议建立在Auth2.0之上，所以，可以将access_token通过Http头的方式来获取权限信息。
（图片来自：WSO2 Blog）
洞见上有两篇文章，《登录工程：现代Web应用中的身份验证技术》和《登录工程：传统 Web 应用中的身份验证技术》，它们很详细的描述了传统Web和现代Web鉴权授权方式的功能需求。
现代Web服务化的普及，迫切需要将账号服务、鉴权服务、授权服务单独拆分，以独立的方式为其他Service提供服务，而这些服务需要提供双阶段认证机制（two-factor-authentication）、基于时间的一次性密码算法、复杂的密码策略、第三方登录系统接入（Github,Google,SAML IdP,OpenID Connect OP），将这些功能全部实现，那么它也就成了Keycloak。
优缺点
Keycloak的优点和缺点都非常明显。
优点包括：
集群配置
应用轻量级
文档简洁全面
样式可完全自定义
丰富的第三方适配
样例丰富
配置版本化管理等
并且，所有操作提供RESTful接口，可简单的通过API接口进行配置。
缺点包括：
很多范例使用JSP、Servlet，对使用SpringBoot的用户不太友好；
导入导出配置仅可以在启动时设置，这个在使用Docker容器时，极其不友好；
授权访问配置导出尚存在Bug；
授权Filter存在Bug，Issue已存在，但未修复；第五，相比Okta，Auth0配置说明及范例较少。
雷达路线及对比
翻阅雷达发现，SSO的应用很早便开始，OpenAM首次在2015年5月的雷达上出现在“评估”位置，对于OpanAM的态度，雷达是这样的：
“由于OpenAM 历史悠久，因此它的代码库很庞大，并且文档也很难理解。希望在不久后，会有一个更轻量级的，对自动化部署和配置提供更好支持的替代方案出现。”
在“评估”两期后，即不再出现。与Keycloak同期存在的还有更稳当的Auth0，它是一款商业的SSO平台，处在“试验”的位置，也就是说，Keycloak真正接替了OpenAM，同时它也满足了雷达提出的愿景——轻量级，支持自动化部署，配置友好。
总结
还是很看好Keycloak发展的，它是JBoss/Redhat下的一个项目，所以有较为坚实的技术支撑，而且，JBoss/Redhat也使用了Keycloak作为它的SSO系统。但是，它的普及率不是很高，所以出现问题所能查到的资料有限。因此，如果能够得到更多的推广和支持，Keycloak在现代Web环境下，可能会有更好的发展。
