Keycloak 适配器弃用

2022 年 2 月 04 日作者：Stian Thorgersen

这篇文章发布已超过一年。博客文章中的内容可能已过时。

早在 2013 年我们开始 Keycloak 项目时，还缺少客户端库来帮助开发人员使用 Keycloak 安全地保护他们的应用程序。快进到今天，情况已经发生了巨大的变化，OAuth 2.0 和 OpenID Connect 库已得到广泛应用。

此外，Keycloak 适配器没有得到它们需要的关注和重视，现在在它们支持的功能方面已显著落后于服务器。虽然 Keycloak 可以用于保护任何应用程序的安全，无论编程语言和框架如何，但我们只为有限的 Java 开发人员提供了适配器。

与其继续分散精力，我们决定弃用适配器，并将更多精力集中在 Keycloak 服务器上。此外，我们的目标是提供关于如何使用入门指南来保护各种应用程序的帮助和指导，并倡导我们认为比 Keycloak 适配器更好的替代方案。

哪些内容将被弃用

哪些内容不会被弃用

替代方案

WildFly 25 引入了对 OpenID Connect 的原生支持，具有 Keycloak 适配器的所有功能以及更多。迁移到 WildFly 原生 OpenID Connect 非常容易，因为 WildFly 团队非常注意使迁移尽可能简单。

请查看 Farah Juma 的这篇精彩博客文章了解更多详情。

长期以来，Spring Security 一直为 OAuth 2.0 和 OpenID Connect 提供出色的支持。我们理解从 Keycloak 适配器迁移到 Spring Security 并非易事，但作为交换，您将获得更多功能、维护更好的库以及与 Spring 更好的集成。

请查看 Ger Roza 的这篇精彩博客文章了解更多详情。

虽然不是现有 Keycloak 适配器的直接替代品，但值得强调的是，Quarkus 对 OpenID Connect 和 Keycloak 具有非常广泛的内置支持，并在其基础上提供了许多额外的优势。

请查看 Quarkus 安全指南了解更多详情。

我们仍在为 Node.js 应用程序寻找最佳候选方案，但看起来 openid-client 是一个不错的替代方案，它比 Keycloak 适配器功能更丰富。

如果您有任何问题、疑虑或建议，请加入我们的 GitHub Discussions 讨论此话题。

如果社区中有人愿意主动站出来继续维护已弃用的 Keycloak 适配器，请通过开发者邮件列表与我们联系。

我们也欢迎关于为每个人找到最佳替代方案以及提供入门指南、迁移指南等的建议和帮助。为了在这方面帮助我们，请加入 GitHub Discussions 上的讨论。

如果您在 2022 年底之前无法迁移离开 Keycloak 适配器，可以考虑的另一种选择是从 Red Hat 获得支持。

Red Hat 通过 Red Hat Single Sign-On 7.x 提供受支持的适配器，目前该版本支持到 2024 年 6 月 30 日。

Red Hat Single Sign-On 支持的适配器包括