For a new integration, OpenID Connect is the preferred choice when the application supports it; SAML 2.0 remains suitable for existing software or products that only support that protocol. Next, configure the OIDC redirect URIs or SAML assertion consumer service endpoints, then connect the application to the realm’s endpoints.

For IT departments, SSO addresses an everyday need: providing access to an entire application portfolio through a single login, with centralised security controls. Keycloak, an open-source identity and access management (IAM) solution, meets this need by centralising authentication.

Keycloak as a central identity provider

Keycloak sits between applications and their users. Users authenticate with Keycloak and, while their SSO session remains valid, can access connected applications without re-entering their credentials. Each application trusts the authentication information provided by Keycloak to establish its own session. This is how an identity provider (IdP) works.

Centralising login offers a tangible security benefit: according to the ENISA Threat Landscape 2025 report, the annual report published by the European Union Agency for Cybersecurity, phishing accounts for approximately 60% of the initial intrusion methods observed in the incidents studied. With Keycloak, multifactor authentication (MFA) policies can be enforced at the shared login point for connected applications. However, not all forms of MFA provide the same protection against phishing: passkeys and WebAuthn are phishing-resistant by design because the authentication key is bound to the domain for which it was created.

Each application maintains its own session. In a full OIDC integration, the application checks the session status with Keycloak and can therefore respond when that session ends. Some applications, however, only verify the JWT’s signature and validity period locally. In this case, a token that is still valid may continue to be accepted after the Keycloak session has ended. This is JWT-based authentication rather than full OIDC session management.

Keycloak supports OpenID Connect (OIDC) and SAML 2.0. Modern applications and existing software can therefore share the same single sign-on within a single realm.

Configure SSO with Keycloak, step by step

The Clever Cloud Keycloak documentation covers service access, realm management, IP address filtering, deployments in Secured Multi Instances mode, and metrics monitoring. For settings specific to OIDC and SAML clients, also refer to the Keycloak administration documentation.

To see the deployment process and interface in practice, watch the video demonstration on our Keycloak as a Service page.

OIDC or SAML 2.0 for SSO: which should you choose?

PoFor new development, choose OpenID Connect when the application supports it. Retain SAML 2.0 for applications whose integration already relies on that protocol or that do not support OIDC:

• OpenID Connect authenticates users of modern web and mobile applications; OAuth 2.0 and its access tokens control access to APIs.
• SAML 2.0 supports existing applications and enterprise software that do not offer OIDC integration.

Keycloak supports both protocols within a single realm. OIDC and SAML applications can therefore share the same single sign-on.

Configure SSO on a managed Keycloak instance

Configuring SSO is only part of the work: a Keycloak server then needs ongoing maintenance, updates, monitoring, and backups. A managed service takes on this operational workload.

Keycloak as a Service, Clever Cloud’s offering operated with the expertise of Please Open It, deploys a managed Keycloak instance hosted in France in just a few clicks. Teams retain control over all settings (realms, clients, and protocols) while Clever Cloud handles infrastructure operations, including ongoing updates, integrated monitoring, and regular backups. When the service is deployed in clustered Secured Multi-Instances mode, multiple nodes distribute the load and improve service continuity. Separately from this architecture, the 99.99% SLA, 24/7 on-call telephone support, and guaranteed response and resolution times are provided through the Premium offering for eligible services. Realm import and export make it easier to migrate an existing instance. Finally, to protect an application without built-in authentication, an authentication proxy such as OAuth2-Proxy adds a login step before users reach the application, without changing its code.

«Keycloak is a Red Hat product, but Red Hat does not provide an open-source LTS version of Keycloak, and security fixes are not backported. Staying on the latest version is therefore essential, and deploying Keycloak as a Service on Clever Cloud makes this much easier. A single realm, separate from master, is often sufficient; multiple realms are only justified when user populations are entirely independent, with no shared applications or with separate deployments. Keycloak also decouples the addition of authentication factors from applications, making it possible to offer the latest authentication factors across all integrated applications. »

— Loïc Mercier des Rochettes, Co-founder and CTO at Please Open It

Evaluating an IAM solution? Our checklist, 11 questions to ask before choosing an identity management solution, brings together the criteria to assess before making a commitment.

FAQ

Does Keycloak support SSO?

Yes. Keycloak is an open-source identity management solution that acts as a central identity provider: applications delegate login to it, and users authenticate only once. It supports OpenID Connect and SAML 2.0.

Should you use OIDC or SAML for SSO with Keycloak?

Both are suitable. OpenID Connect is designed for modern web applications, mobile applications, and APIs; SAML 2.0 remains the established standard for existing enterprise applications. Keycloak handles both protocols in parallel.

How do you connect an application to Keycloak?

Create a client in the relevant realm, then configure it according to the protocol used by the application. For OpenID Connect, this includes configuring its redirect URLs and providing the client ID, the realm’s discovery URL, and a secret only if the application can securely store it. For SAML 2.0, configure the application’s entity ID, its Assertion Consumer Service URL, and the metadata exchange with Keycloak.

Do you need to host Keycloak yourself to implement SSO?

No. A self-hosted Keycloak deployment requires you to manage installation, updates, security, and availability. A managed offering, such as Clever Cloud’s Keycloak as a Service, handles these operations; teams remain responsible for clients, users, permissions, and authentication policies.

Can you secure an existing application without changing its code?

Yes. An authentication proxy such as OAuth2-Proxy, connected to Keycloak, can require users to log in before forwarding requests to the application, without changing its code. This approach is particularly suitable for back-office applications and internal tools without built-in authentication, provided the application cannot be accessed directly by bypassing the proxy. Any application-specific authorisation rules still need to be defined.