Red Hat SSO vs Keycloak: Differences, Support, and Migration

Red Hat SSO vs Keycloak is no longer a simple product comparison. Red Hat Single Sign-On (Red Hat SSO) 7.6 was the final planned release in its product line. Red Hat now offers Red Hat build of Keycloak as its supported identity and access management platform.

Meanwhile, Keycloak remains the upstream open-source project. Both platforms provide single sign-on, identity federation, and centralized access control. However, they differ in support, release timing, certification, lifecycle, and operational responsibility.

This guide explains the current relationship between Red Hat SSO and Keycloak. It also covers migration concerns and the factors that should guide a platform choice.

Red Hat SSO vs Keycloak at a glance

Area	Red Hat SSO and its successor	Keycloak
Current status	Red Hat SSO 7.6 is the final generation. Red Hat build of Keycloak is the replacement.	Active upstream open-source project.
Support	Commercial support follows Red Hat subscription terms and product lifecycles.	Community support unless a third party provides a support contract.
Release approach	Selected upstream changes are tested, packaged, and supported by Red Hat.	New features and changes generally appear upstream first.
Certification	Designed for supported Red Hat environments, including OpenShift and RHEL.	Runs in many environments, but users validate their own deployment choices.
Cost model	Subscription entitlements may be required for supported use.	Software is available under the Apache License 2.0; operating costs still apply.
Best fit	Organizations that need vendor accountability and predictable maintenance.	Teams that prefer rapid upstream releases and community-led development.

What is Red Hat SSO?

Red Hat SSO is the common name for Red Hat Single Sign-On. The product provided web single sign-on and identity federation based on standards such as OpenID Connect, OAuth 2.0, and SAML 2.0. It was derived from Keycloak and packaged for Red Hat customers.

Red Hat SSO 7.6 is the last planned feature release in the 7.x line. Therefore, organizations should not treat it as the long-term destination for a new identity platform. Its successor is Red Hat build of Keycloak, often shortened to RHBK.

Red Hat build of Keycloak keeps the close connection to the upstream project. In addition, it adds a defined support lifecycle, tested packages, security updates, and documentation for supported environments.

What is Keycloak?

Keycloak is an open-source identity and access management platform. It can authenticate users, issue tokens, broker identities, and manage sessions for applications and services. The project is available under the Apache License 2.0.

Keycloak supports common identity standards. These include OpenID Connect, OAuth 2.0, and SAML 2.0. It also provides an administration console, account management, identity brokering, user federation, authentication flows, and authorization services.

The upstream project moves quickly. As a result, teams can adopt new capabilities sooner. However, they must also plan upgrades, test integrations, monitor security notices, and operate the service themselves.

How Red Hat SSO and Keycloak are related

Historically, Red Hat SSO was a downstream product based on Keycloak. Red Hat selected an upstream version, tested it, applied fixes, and supported it for a stated period. Therefore, the two products shared many concepts and features, but their version numbers and release schedules did not always match.

The relationship is now expressed through Red Hat build of Keycloak. This product replaces Red Hat SSO while remaining based on the Keycloak project. Consequently, a modern comparison should consider three terms:

• Red Hat SSO 7.6: the legacy Red Hat product that existing users may still operate.
• Red Hat build of Keycloak: the current supported Red Hat product and migration target.
• Keycloak: the upstream community project.

Key differences in Red Hat SSO vs Keycloak

1. Product lifecycle

Keycloak follows the upstream community release cycle. Releases may add features, change defaults, or remove deprecated behavior. Each deployment team decides how long to remain on a version.

By contrast, Red Hat products use published lifecycle phases. Customers receive fixes according to the applicable support policy. This difference matters when an organization needs predictable maintenance windows or formal vendor commitments.

2. Support and accountability

Community Keycloak users rely on public documentation, issue tracking, discussion channels, and their own engineering resources. That model can work well for teams with strong Java, security, database, and platform skills.

A supported Red Hat deployment adds access to vendor support under the relevant subscription. It can also simplify escalation when a production defect affects a supported configuration. Nevertheless, a subscription does not remove the need for sound architecture, monitoring, backups, or upgrade testing.

3. Release speed

Upstream Keycloak usually exposes new work first. This can benefit teams that need a recently added protocol feature or extension point. However, faster change may increase testing effort.

Red Hat build of Keycloak follows a curated product schedule. Thus, it can lag behind the newest community release while providing a more controlled support baseline. Neither approach is universally better; the right choice depends on risk tolerance and release governance.

4. Platform validation

Keycloak can run on containers, Kubernetes, virtual machines, and physical hosts. Still, community availability does not mean that every combination of operating system, database, Java runtime, proxy, and storage layer has been validated for a particular workload.

Red Hat build of Keycloak documents supported configurations and is optimized for Red Hat platforms. This is especially relevant for organizations that standardize on OpenShift or RHEL and want one vendor to support more of the stack.

5. Cost and staffing

Keycloak does not charge a software license fee. Yet a production service still requires infrastructure, engineering time, observability, incident response, security maintenance, and disaster recovery.

Red Hat build of Keycloak may require an eligible subscription. In return, it offers a supported distribution and lifecycle. Therefore, compare total operating cost rather than license price alone.

6. Customization

Both options support custom themes, authentication flows, and service provider interfaces. Custom code can solve important requirements. However, it also creates upgrade work and security responsibility.

Use built-in standards and configuration where possible. In addition, keep extensions small, versioned, tested, and documented. This advice applies whether the deployment uses upstream Keycloak or a Red Hat build.

Shared identity and access management capabilities

The feature set varies by release, but the platforms share a common foundation. Typical capabilities include:

• Single sign-on and single logout.
• OpenID Connect, OAuth 2.0, and SAML 2.0 support.
• Identity brokering with external identity providers.
• User federation with LDAP or Active Directory.
• Multi-factor and passwordless authentication flows.
• Centralized session and token management.
• Role-based access controls and authorization services.
• Administrative interfaces and APIs.
• Custom themes, event listeners, and provider extensions.

Exact feature maturity and support status can differ. Therefore, validate each required capability against the documentation for the specific version you plan to deploy.

Migration from Red Hat SSO 7.6

Organizations still using Red Hat SSO 7.6 should plan a migration to Red Hat build of Keycloak. This is more than a routine patch because the newer server uses the Quarkus-based distribution instead of the former JBoss EAP-based server.

Configuration also changes. Files and management methods used by Red Hat SSO, such as standalone.xml and older command-line workflows, do not map directly to the current configuration model.

A controlled migration should include these steps:

1. Inventory realms, clients, identity providers, user federation, themes, extensions, and adapters.
2. Review every intervening release note and migration guide.
3. Back up the database and test a verified restore procedure.
4. Build the new configuration for the supported Keycloak distribution.
5. Test protocol flows, token claims, redirects, logout, and session behavior.
6. Update or replace application adapters that are no longer provided.
7. Run performance, failover, and security tests in a non-production environment.
8. Prepare rollback criteria and monitor closely after cutover.

Never point an old and a new server at the same database at the same time during migration. Also, test custom providers and themes carefully because internal interfaces and templates may have changed.

Which option should you choose?

Choose upstream Keycloak when your team values early access to community releases and can own the full operational lifecycle. It is also suitable when you need broad deployment flexibility and have the expertise to validate the complete stack.

Choose Red Hat build of Keycloak when vendor support, documented platform compatibility, and a predictable lifecycle are primary requirements. It is often the clearer choice for organizations already standardized on Red Hat subscriptions and OpenShift.

If you currently run Red Hat SSO, the decision is different. The practical path is to assess migration to Red Hat build of Keycloak rather than start a new Red Hat SSO deployment.

Security and operational considerations

Whichever option you select, treat the identity platform as critical security infrastructure. Use supported databases, encrypted connections, strict administrative access, and separate production credentials. Rotate keys and secrets according to policy.

In addition, centralize audit events and monitor login failures, administrator actions, and unusual token activity. Maintain tested backups. Finally, apply security updates promptly and rehearse recovery procedures before an incident occurs.

Frequently asked questions

Is Red Hat SSO the same as Keycloak?

No. Red Hat SSO was a supported Red Hat product derived from the Keycloak project. They shared a code base and many features, but they had different release schedules, packaging, testing, and support terms.

What replaced Red Hat SSO?

Red Hat build of Keycloak replaces Red Hat Single Sign-On. Red Hat SSO 7.6 was the final planned release in the older product line.

Is Keycloak free?

Keycloak is open-source software under the Apache License 2.0. However, infrastructure, staffing, maintenance, monitoring, upgrades, and optional commercial support still create costs.

Can Red Hat SSO be upgraded directly to current Keycloak?

A migration is possible, but it requires careful planning. The runtime, configuration model, database migration, application adapters, custom providers, and themes may all need changes. Follow the migration guidance for the exact source and target versions.

Conclusion

The central difference in Red Hat SSO vs Keycloak is not the basic IAM feature set. It is the product model. Keycloak is the fast-moving upstream community project, while Red Hat provides a tested and supported downstream offering with a defined lifecycle.

For new supported Red Hat deployments, evaluate Red Hat build of Keycloak instead of the legacy Red Hat SSO product. For upstream deployments, make sure the team can own upgrades, security maintenance, availability, and integration testing. A clear operating model is just as important as the software choice.