Keycloak首次在ThoughtWorks技術(shù)雷達(dá)VOL’16中以“評估”的狀態(tài)出現(xiàn)。

技術(shù)雷達(dá)15期正式提出“安全是每一個(gè)人的問題”锻离，同時(shí)也對Docker和微服務(wù)進(jìn)行了強(qiáng)調(diào)。

在微服務(wù)盛行的時(shí)代仇让，現(xiàn)代Web服務(wù)的拆分對鑒權(quán)和授權(quán)也提出了新的挑戰(zhàn)那槽，而這正是Keycloak解決的問題。

用一句Keycloak官方語言來解釋屿笼，“為現(xiàn)代應(yīng)用系統(tǒng)和服務(wù)提供開源的鑒權(quán)和授權(quán)訪問控制管理”牺荠。

Keycloak實(shí)現(xiàn)了OpenID，Auth2.0驴一，SAML單點(diǎn)登錄協(xié)議休雌，同時(shí)提供LDAP和Active Directory，以及OpenID Connect, SAML2.0 IdPs肝断，Github杈曲，Google等第三方登錄適配功能，能夠做到非常簡單的開箱即用胸懈。但是在實(shí)際上担扑，如果想稍微順利的添加配置，還是需要簡單的了解SSO趣钱，若想要配置更加復(fù)雜的場景涌献，則需要了解對應(yīng)的協(xié)議。

原理概念普及

（圖片來自：SAML2.0 wiki）

上圖是使用SAML協(xié)議時(shí)首有，用戶首次登錄的一種最常用的工作流（SP Redirect Request; IdP POST Response）燕垃，也是Keycloak的默認(rèn)方式（當(dāng)選擇SAML協(xié)議時(shí)），如果忽視傳輸內(nèi)容（SAML基于xml傳輸井联，OpenID普通文本）的不同卜壕，這種工作流程與OpenID的流程非常相似，可以用它來大致了解登錄流程低矮。

用戶請求Service Provider（簡稱SP）印叁，通過SessionID判斷是否存在已鑒權(quán)的Context，否則返回302，重定向至Identity Provider（簡稱IdP）轮蜕，并攜帶參數(shù)昨悼，IdP檢測是否已經(jīng)存在鑒權(quán)Context，否則要求用戶提供憑證（例如普通的用戶名密碼輸入框）跃洛，成功后返回302率触，并將數(shù)據(jù)返回給SP。在此流程中汇竭，單點(diǎn)登錄能夠做到的非常關(guān)鍵的一點(diǎn)就是Web中的鑒權(quán)Context葱蝗，這種方式的實(shí)現(xiàn)原理也就是利用了Cookie（Web Session的實(shí)現(xiàn)），多個(gè)SP對應(yīng)一個(gè)IdP细燎，任一臺SP登錄成功两曼，IdP即有了鑒權(quán)Content，隨后其他SP即可直接登錄玻驻，這個(gè)過程可簡單的觀察瀏覽器地址欄變更或查看瀏覽器網(wǎng)絡(luò)請求過程悼凑。

另一種方式是針對提供RESTFull Api的服務(wù)，這種情況下必須使用OpenID Connect協(xié)議璧瞬，這種協(xié)議建立在Auth2.0之上户辫，所以，可以將access_token通過Http頭的方式來獲取權(quán)限信息嗤锉。

（圖片來自：WSO2 Blog）

洞見上有兩篇文章渔欢，《登錄工程：現(xiàn)代Web應(yīng)用中的身份驗(yàn)證技術(shù)》和《登錄工程：傳統(tǒng) Web 應(yīng)用中的身份驗(yàn)證技術(shù)》，它們很詳細(xì)的描述了傳統(tǒng)Web和現(xiàn)代Web鑒權(quán)授權(quán)方式的功能需求∥脸溃現(xiàn)代Web服務(wù)化的普及奥额，迫切需要將賬號服務(wù)、鑒權(quán)服務(wù)酷誓、授權(quán)服務(wù)單獨(dú)拆分披坏，以獨(dú)立的方式為其他Service提供服務(wù)，而這些服務(wù)需要提供雙階段認(rèn)證機(jī)制（two-factor-authentication）盐数、基于時(shí)間的一次性密碼算法棒拂、復(fù)雜的密碼策略、第三方登錄系統(tǒng)接入（Github,Google,SAML IdP,OpenID Connect OP）玫氢，將這些功能全部實(shí)現(xiàn)帚屉，那么它也就成了Keycloak。

優(yōu)缺點(diǎn)

Keycloak的優(yōu)點(diǎn)和缺點(diǎn)都非常明顯漾峡。

優(yōu)點(diǎn)包括：

• 集群配置
• 應(yīng)用輕量級
• 文檔簡潔全面
• 樣式可完全自定義
• 豐富的第三方適配
• 樣例豐富
• 配置版本化管理等

并且攻旦，所有操作提供RESTFull接口，可簡單的通過Api接口進(jìn)行配置生逸；

缺點(diǎn)包括：

• 很多范例使用JSP牢屋、Servlet且预，對使用Springboot的用戶不太友好；
• 導(dǎo)入導(dǎo)出配置僅可以在啟動時(shí)設(shè)置烙无，這個(gè)在使用Docker容器時(shí)锋谐，極其不友好；
• 授權(quán)訪問配置導(dǎo)出尚存在Bug截酷；
• 授權(quán)Filter存在Bug涮拗，Issue已存在邀桑，但未修復(fù)默穴；第五，相比Okta脯爪，Auth0配置說明及范例較少三幻。

雷達(dá)路線及對比

翻閱雷達(dá)發(fā)現(xiàn)就漾，SSO的應(yīng)用很早便開始，OpenAM首次在2015年5月的雷達(dá)上出現(xiàn)在“評估”位置赌髓，對于OpanAM的態(tài)度从藤，雷達(dá)是這樣的：

由于OpenAM 歷史悠久催跪，因此它的代碼庫很龐大锁蠕，并且文檔也很難理解。希望在不久后懊蒸，會有一個(gè)更輕量級的荣倾，對自動化部署和配置提供更好支持的替代方案出現(xiàn)骑丸。

在評估兩期后，即不再出現(xiàn)通危。與Keycloa同期存在的還有更穩(wěn)當(dāng)?shù)腁uth0，它是一款商業(yè)的SSO平臺菊碟，處在“試驗(yàn)”的位置节芥，也就是說逆害，Keycloak真正接替了OpenAM头镊，同時(shí)它也滿足了雷達(dá)提出的愿景——輕量級，支持自動化部署魄幕，配置友好相艇。

總結(jié)

還是很看好Keycloak發(fā)展的，它是Jboss/redhat下的一個(gè)項(xiàng)目纯陨，所以有較為堅(jiān)實(shí)的技術(shù)支撐坛芽，而且留储，Jboss/redhat也使用了Keycloak作為它的SSO系統(tǒng)。但是咙轩，它的普及率不是很高欲鹏，所以出現(xiàn)問題所能查到的資料有限。因此臭墨，如果能夠得到更多的推廣和支持赔嚎，Keycloak在現(xiàn)代Web環(huán)境下，可能會有更好的發(fā)展胧弛。

參考資源

• 官方文檔: http://www.keycloak.org/documentation.html
• OpenID協(xié)議:http://openid.net/developers/specs/
• Auth2.0協(xié)議:https://tools.ietf.org/html/rfc6749
• SAML2.0協(xié)議:https://en.wikipedia.org/wiki/SAML_2.0
• SSO相關(guān)資源:https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
• Keycloak源碼:https://github.com/keycloak/keycloak
• 基于Springboot, React實(shí)現(xiàn)的Demo:https://github.com/yourwafer/keycloak-sso