Keycloak 适配器弃用

2022 年 2 月 4 日，作者：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 讨论讨论此主题。

如果社区中的任何人愿意参与并继续维护已弃用的 Keycloak 适配器，请通过开发者邮件列表与我们联系。

我们也欢迎大家为我们提供建议和帮助，以便找到适合所有人的最佳替代方案，并提供入门指南、迁移指南等。要帮助我们做到这一点，请加入 GitHub 讨论中的讨论。

如果您无法在 2022 年底之前从 Keycloak 适配器迁移，可以考虑从 Red Hat 获取支持。

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

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