Keycloak SSO integration starts with the application inventory, not the client form
Keycloak SSO integration means registering each application as an OpenID Connect or SAML 2.0 client in a realm, with exact redirect rules, token settings and the claims that application is allowed to use. The inventory comes first because each application's answers to those questions determine the client settings, and filling in the client form before you know them is how most integration problems start. For every application, record the protocol its library supports, the hostnames and paths it will send users back to, whether it runs a server-side component that can keep a secret, which roles and groups it needs, and how its users are expected to sign out.
Several of the hard parts are easy to miss at the form. A redirect URI that differs by a trailing slash, a port or a scheme from the registered value will fail at sign-in, and wildcards widen what Keycloak will accept, so each entry should be exact and reviewed. The choice between a public client and a confidential client changes whether a client secret exists at all, which matters for single-page and mobile apps that cannot protect one. Roles and groups can exist in the realm and still never reach the token unless a mapper includes them in the claim the application reads, so test a real login and inspect the token rather than trusting the admin console.
Session behavior and logout need the same scrutiny. Users often assume that closing one application ends their session everywhere, but the application's own session, the Keycloak browser session and any tokens it holds have separate lifetimes, and a single application can clear only its own session unless back-channel or front-channel logout is configured across all clients. Agree with each application owner what should happen when a user signs out, what happens when the session expires, and how long a token may be used before the application asks again. Confirm these values against the server administration guide for your Keycloak version instead of relying on memory or defaults from another product.
The Keycloak server administration guide documents the protocols, client settings, mappers and logout options in detail, and it is the reference your team should work from. The actual integration, however, depends on the application's own authentication library and on how that library validates tokens: which issuer and audience it checks, whether it verifies signatures against published keys, and which claims it reads. Ask each application team to name the library and version and to show how it handles the redirect, the token and the logout callback. Those answers, collected before any client is created, make the client registration a short, reviewable step.
Which Keycloak objects carry SSO and identity integration
Most SSO problems in Keycloak trace back to a small set of objects: the realm, the clients, the scopes and mappers that shape tokens, the roles and groups that carry authorization, and the discovery endpoints applications read. Understanding what each one controls, and what breaks when it is misconfigured, tells you where to spend review time before any application goes live.
Realms as the tenant boundary
A realm is the boundary that holds users, clients, keys, roles and authentication settings. Users in one realm cannot sign in to clients in another, so the realm split decides who can be federated, which signing keys apply and which administrators can change what. Check early whether environments, business units or customer groups belong in separate realms, because moving users and clients between realms later is a migration project rather than a setting change.
OIDC and SAML client configuration
Each application is registered as a client, and the protocol chosen (OpenID Connect or SAML 2.0) determines how redirect URIs, signing and assertion consumer settings are validated. A wrong redirect URI or a mismatched SAML entity ID causes sign-in to fail or, worse, to return tokens to the wrong place. Confirm for each client whether it is public or confidential, which flows it may use and exactly which redirect targets are allowed.
Client scopes and protocol mappers
Client scopes and protocol mappers decide which claims appear in ID tokens, access tokens and SAML assertions. An application that reads an email, group or tenant claim will fail silently if a mapper is missing or assigns the wrong attribute. Review the exact claims each application expects, then confirm that mappers add them to the right token type and that unneeded personal data is not included.
Realm and client roles
Roles express what a user may do, and Keycloak can define them at realm level or inside a single client. Realm roles suit enterprise-wide permissions, while client roles keep an application's permissions scoped to that application. When a role is missing from a token or assigned in the wrong scope, applications deny access that looks correct in the console, so check the role scope and whether the mapper emits it.
Groups and group membership
Groups organize users and can grant role mappings to everyone inside them, which simplifies large-scale access management. Group membership changes take effect only when tokens are issued again, so a removed member may keep access until an existing session or token expires. Decide whether groups or direct role assignments are the source of truth, and confirm that any directory-synchronized groups are not edited by hand in Keycloak.
Discovery and SAML metadata endpoints
Each realm publishes an OpenID Connect discovery document and a SAML descriptor that applications use to learn issuer, endpoint, key and binding details. Applications that cache these documents or hold old signing certificates break when keys rotate or hostnames change. Confirm that the public frontend URL in the discovery and descriptor output matches what users and applications actually reach, especially behind a reverse proxy.
Session and token lifetime settings
Realm-level session and token settings control how long SSO sessions last, how long access and refresh tokens remain valid and when idle sessions expire. Short lifetimes improve revocation but increase sign-in prompts and refresh traffic, while long lifetimes widen the window after a stolen token or a departed user. Agree these values with the security owner for each client type and test logout and refresh behavior before go-live.
Which protocol, client type and realm layout to choose
This table compares the main Keycloak configuration choices for each application and shows what each one costs to operate over time. Read each row as a decision point: the option column names the choice, and the other columns explain when it fits and which recurring tasks it adds. The main takeaway is that most long-term operating cost comes from secrets, certificates, realm exports and token size, so settle those choices before the first client is registered.
| Decision | When it fits | Operational cost |
|---|---|---|
| OpenID Connect versus SAML 2.0 | OIDC for modern web, mobile and API applications. SAML 2.0 for older enterprise applications that only support SAML assertions. | SAML requires managing a realm signing key and certificate, with renewal scheduled before expiry and the new certificate shared with each service provider. OIDC adds client secret rotation for confidential clients but no separate certificate cycle. |
| Confidential client versus public client | Confidential clients suit server-side applications that can keep a secret. Public clients suit single-page apps and native mobile apps, which must use PKCE because they cannot hold a secret. | Confidential clients need secret rotation on a schedule and secure storage in the application's deployment pipeline. Public clients avoid secret rotation but depend on PKCE and correct redirect URI configuration. |
| One realm for all applications versus separate realms | One realm suits applications under one trust boundary and one set of users. Separate realms suit different environments, such as production and test, or users that must not share credentials or policies. | A single realm is simpler to administer but concentrates changes. Separate realms multiply admin work, configuration baselines and exports, and each realm needs its own client and role maintenance. |
| Client roles, realm roles and groups | Client roles scope permissions to one application. Realm roles suit cross-application permissions. Groups suit assigning a bundle of roles to many users, often mapped from a directory. | Each mapping needs review as applications change. Heavy use of realm roles across many clients can make the role model hard to audit. Group membership sync from a directory adds a dependency to check after directory changes. |
| Access tokens for APIs via audience or a dedicated client scope | Use the audience claim when one client calls several APIs. Use a dedicated client scope that adds the API audience and specific roles when each API needs its own token contents. | Every role and group claim added to tokens increases token size. Large tokens can exceed header limits at the reverse proxy or in the browser, so confirm limits in your environment and test with realistic role counts. |
| Realm export and configuration drift | Exports suit baseline comparisons and disaster recovery. Infrastructure-as-code or realm import files suit repeatable environment builds. | Manual console edits drift away from exports over time. Exports can include or omit secrets depending on options used, so confirm the export handling policy before storing them in source control. |
How to build Keycloak SSO integration in order
This sequence takes an application estate from an inventory of protocols and redirect URIs to a tested, exported Keycloak configuration that single sign-on, token claims and logout behave as each application expects. Each step closes with a check that the team can repeat in a non-production realm before changes reach production.
Inventory each application and its requirements
Start by listing every application that will sign in through Keycloak. For each one, record the protocol it speaks (OpenID Connect or SAML 2.0), whether it is a confidential server-side client, a public client such as a single-page or mobile app, or a bearer-only API, the exact redirect and post-logout URIs, and the claims or roles it expects in tokens or assertions. Application owners should confirm these values in writing. The output is a single register that the platform team signs off on. The step is done when every application has a row with no blank protocol, client type or redirect field.
Create or select the realm and login flow
Decide whether the applications share one realm or need separate realms, based on user population, admin separation and branding. Create the realm in a non-production environment first, then set the browser login flow, required actions and password or passkey policy that the applications will use. Confirm the realm's frontend URL matches the public hostname, and keep the admin console on a separate hostname as the production guide describes. The check is a successful login to the Keycloak account page from a clean browser profile, with the realm name and issuer URL recorded in the decision log.
Register each OIDC client with exact URIs
Create one client per application in the realm. Enter redirect URIs and post-logout redirect URIs exactly as the application uses them, avoiding wildcards in production unless the application owner accepts the risk in writing. Set confidential or public client type to match step one, and enable PKCE with the S256 method for every public client. Keep client secrets in a secrets manager, not in the realm export. The check is a sign-in attempt from each application that completes the authorization code flow, plus a rejected attempt using a deliberately wrong redirect URI to confirm the match is strict.
Map roles, groups and attributes into tokens
Configure protocol mappers on each client so that roles, groups and user attributes appear in the ID token, access token or SAML assertion the application reads. Use client scopes where several applications need the same claims, and name each claim exactly as the application code expects. Avoid placing large group lists in tokens; prefer role names the application can check. The check is decoding a test ID token and access token from a test user and comparing each claim name and value against the application's expected schema.
Set session and token lifetimes per client
Review the realm defaults for access token lifetime, SSO session idle and maximum, and refresh token behavior, then override them per client only where an application's risk profile requires it. Record each value and the reason in the decision log, since these settings drive how often users re-authenticate. Ask the security owner to confirm the values before go-live, because they are policy choices rather than technical defaults. The check is a test session that expires at the configured idle time and a refresh that succeeds or fails as the settings predict.
Exchange SAML metadata and test signed assertions
For each SAML 2.0 application, exchange metadata in both directions, confirming entity IDs, assertion consumer service URLs, signing certificates and name ID format. Configure the client to require signed assertions, and verify the signing certificate expiry date and rotation plan with the application owner. Then run a login from a clean browser and inspect the returned assertion. The check is a completed SAML login in which the assertion signature validates and the attributes match the register from step one.
Register APIs as resource servers with audience checks
Where an API accepts tokens issued by Keycloak, register it as a resource server or client with a defined audience, and add an audience mapper to the clients that call it. The API must reject tokens whose audience does not match its own identifier, and must validate the issuer and signature against the realm's keys. Document which scopes and roles each endpoint requires. The check is calling the API with a token for the correct audience, which should succeed, and with a token for a different audience, which should be refused.
Configure front-channel and back-channel logout
Set front-channel logout URLs for browser-based applications and back-channel logout URLs for server-side applications that can receive logout tokens. Confirm each application's logout endpoint and whether it expects a session identifier in the logout token. For Keycloak 26.8 and later, the upgrade notes make signature validation of backchannel logout tokens from external providers mandatory, so confirm that the receiving applications validate signatures as well. The check is signing out in one application and confirming that a second application signed in through the same realm also ends its session.
Export realm configuration as code and record decisions
Export the realm configuration with secrets removed and store it in version control, then keep a decision log covering realm choices, token lifetimes, mapper names, logout behavior and any exceptions granted. Repeat the export and import into a fresh non-production instance to confirm the configuration rebuilds without manual steps. Confirm the log names an owner for each application. The check is a clean import into an empty Keycloak instance, followed by a sign-in test for one application from each protocol, which completes the build sequence.
How web, mobile and API clients differ in a Keycloak SSO design
Each kind of client in a Keycloak SSO design needs different settings, and the first decision is which of three patterns each application follows: a web application with a server-side component, a single-page or mobile app, or an API. Getting this classification right before client registration prevents the most common mistakes, such as shipping a client secret inside a browser bundle or accepting tokens meant for a different application. Ask each application owner whether a backend process holds a secret that the browser never sees. That answer decides the client type in the Keycloak admin console.
Web applications with a server-side component can usually be registered as confidential clients. The server exchanges the authorization code for tokens using a client secret or another client authentication method that your team selects, so the secret and tokens stay off the browser. Confirm the client authentication method your framework supports and where the secret will be stored, for example in a secrets manager rather than in configuration files committed to source control. Redirect URIs should still be listed exactly, because a broad wildcard lets an attacker redirect an authorization response to a host they control.
Single-page apps and mobile apps are public clients. They cannot keep a secret, so they use the authorization code flow with Proof Key for Code Exchange (PKCE), which binds the code exchange to a value only the client holds. Register strict redirect URIs, including the exact custom scheme or loopback address that a mobile app uses, and keep access token lifetimes short so that a leaked token has limited use. Refresh tokens for public clients need a deliberate policy in the realm and client settings. Confirm that the mobile SDK and the single-page framework library in your stack support PKCE and handle token storage and renewal as you expect.
APIs do not sign users in. Each API receives an access token and must validate it before acting: check the signature against the realm keys, confirm the issuer matches the realm, confirm the audience includes the API, and read roles or scopes from the claims your authorization model relies on. Many libraries validate issuer and signature by default but not audience, so test that path explicitly with a token issued for a different client. Single sign-on works across the web applications because one realm session lets several of them sign in silently. Mobile and API tokens, however, have their own lifetimes and refresh behavior, so test each client type separately rather than assuming one successful browser login proves the others.
Federated identity adds one more check. The Keycloak 26.8 upgrade notes make signature validation of backchannel logout tokens from external providers mandatory, so a logout signal from a brokered identity provider that is not correctly signed will not be accepted. Plan a test where a logout from the upstream provider reaches Keycloak and the relevant sessions end, and confirm the upstream provider's signing keys are configured for the realm. Review the upgrade notes for the version you deploy, since behavior changes of this kind are central to planning any upgrade.
What drives the effort and cost of each SSO integration
This table lists the drivers that change how much work a Keycloak SSO integration takes, why each one matters, and how to keep it contained. Read each row against the build sequence, because the driver usually shows up as a specific task. Scope and cost follow from a written inventory of applications, client types, mappings and environments, so the inventory is the first thing to agree on.
| Driver | Why it changes the work | How to keep it down |
|---|---|---|
| Number of applications and protocols | Each OpenID Connect client needs its redirect URIs, scopes and secrets set up, and each SAML application needs metadata exchange, signing and encryption certificate handling, and attribute statements. | Group applications by protocol and agree on one pattern per type. Confirm which applications support OIDC and which only support SAML before build starts. |
| Number of client types | Web apps with a server-side backend, single-page apps and mobile apps each need different client settings, such as confidential or public clients, PKCE and redirect rules. API resources add audience and scope configuration. | Define a small set of client templates and reuse them. Ask each application team which client type it is before the client registration step, not after. |
| Claim and role mapping complexity | Mapping user attributes, groups and realm or client roles into token claims is done per client and per consumer. Each unusual claim shape adds testing and can break an application that reads it. | Keep one canonical claim set and document it. Limit custom mappers to claims an application truly needs, and record which team owns each mapper. |
| Environments (dev, test and production realms and certificates) | Each environment needs its own realm or configuration, client secrets, signing keys, certificates and hostnames. Promotion steps must move configuration without copying secrets or test users into production. | Export realm configuration as code from a single source, keep secrets in the client's secret store, and confirm the certificate and hostname plan for each environment during design. |
| Application teams' ability to validate tokens correctly | Applications must verify signatures, issuer, audience, expiry and nonce or state values. Weak validation is the most common reason a working login becomes a security defect, and fixing it pulls in application developers. | Ask teams to name their token library and validation approach early. Provide a test checklist and a sample integration in a non-production environment before cutover. |
| Logout requirements across applications | Single logout needs front-channel or back-channel logout endpoints in each client, session tracking, and testing across every application in a session. Backchannel logout tokens from external providers must have their signatures validated. | Decide per application whether local logout is acceptable or whether single logout is required. Limit single logout to applications where the business case is confirmed, and test it end to end. |
| Compliance evidence such as exported configuration and access reviews | Assessors usually ask for the realm and client configuration as it existed at a point in time, change records, and periodic reviews of who can access which clients and roles. Collecting this after go-live is slow. | Set up configuration export and change tracking during build. Agree on the access review cadence and the owner of each review with the client before go-live. DeployOpen prepares this evidence but does not issue audit reports. |
| Written inventory as the basis for scope and cost | Every driver above changes the task list. Without a written inventory of applications, protocols, client types, mappings and environments, the work cannot be scoped or quoted reliably. | Build the inventory first, with one row per application, and review it with the application owners. Confirm open items in writing before any build work is scheduled. |
How SSO integration changes by deployment model
On a single node, Keycloak runs as one instance with one hostname, so the endpoints applications use are easiest to predict. The issuer URL is the one place applications learn where Keycloak lives. Its discovery document lists the authorization, token, userinfo, JWKS and logout endpoints, and every relying party validates the iss claim in issued tokens against that value. If the hostname is set incorrectly, sign-in may appear to succeed while token validation fails in the application.
Points to check:
- Set the public hostname and frontend URL once, and confirm the issuer in the discovery document matches exactly what each application is configured to expect, including scheme, host and any path prefix.
- Confirm that TLS terminates in front of or on the node and that redirects do not downgrade to plain HTTP.
- Keep the admin console and Administration REST API on a different hostname or context path from the public frontend URL, as the production guide recommends.
- Record the issuer value per realm, since a realm rename or hostname change alters every client's configuration.
- Test a full sign-in and token refresh from each application, not only the login page.
Before go-live, compare the issuer string in each application's configuration with the value the single node publishes.
In a high availability design, several Keycloak nodes serve the same realms, so every node must present the same issuer. Clients and relying parties must not see a different hostname depending on which node answered. The usual pattern places a load balancer in front of the nodes, with one public hostname for all of them. The architecture choice itself, including the cluster layout, database replication and session handling, is covered in the Keycloak high availability sibling topic.
Points to check:
- Configure all nodes with the same public hostname and frontend URL so the issuer is identical behind the load balancer.
- Confirm the reverse proxy passes forwarded headers such as the original scheme, host and client address, so Keycloak builds correct redirect and discovery URLs.
- Verify that the proxy trusts those headers only from itself, so clients cannot spoof them.
- Check that discovery and JWKS responses are the same from each node by requesting them directly and through the load balancer.
- Test sign-in and logout while a node is removed from rotation, because redirect URIs built from a wrong host will fail only in some requests.
The forwarded header configuration is the most common source of mixed issuer values in this model, so verify it before relying on the load balancer health checks.
With the Keycloak Operator, the operator manages the Keycloak deployment and, through the KeycloakOIDCClient and KeycloakSAMLClient custom resources, manages client definitions as Kubernetes objects. This lets teams store client configuration in version control, review changes through the same process as other manifests, and promote them between environments. The operator does not remove the need for environment-specific values, so the operator-managed definitions still carry the redirect URIs and root URLs for each cluster.
Points to check:
- Keep client resources in version control, with environment overlays that set redirect URIs, web origins and root URLs per environment rather than copying one set of values everywhere.
- Confirm that the hostname used by the ingress matches the frontend URL configured on the Keycloak resource.
- Review the operator update approval setting, since the operator documentation strongly recommends manual approval to avoid unintended upgrades.
- Verify that the client secret source is a Kubernetes secret managed through your normal secret process, not a value committed to the repository.
- Check that SAML clients receive the correct entity IDs and assertion consumer URLs in each environment.
Before each promotion, compare the rendered redirect URI list for the target environment with the list the application expects.
In an air-gapped network, applications and Keycloak cannot reach public services. Relying parties often expect to fetch discovery documents, signing keys and, for some libraries, metadata from the identity provider or from public content delivery networks. Those fetches fail or hang if the endpoints are not reachable inside the network. Application libraries and metadata files also need to be hosted internally, since package installation and public documentation links will not work from the isolated segment.
Points to check:
- Host application libraries, container images and any SAML metadata files on internal mirrors or registries before the build starts.
- Confirm that all discovery, JWKS, token and logout endpoints resolve and respond inside the network, with internal DNS and certificates trusted by each application.
- Check that any external identity provider or social login that the design depends on is either removed or reached through an approved path, since brokering to public providers will not work from an isolated network.
- Verify that email, metrics and log destinations are internal, because Keycloak features that send mail or export data will otherwise fail silently.
- Test a complete sign-in, token refresh and logout from each application inside the isolated segment.
Confirm the list of endpoints with the network team before cutover, because a single unresolved key endpoint can block every application that validates tokens.
How to secure SSO clients, tokens and SAML trust
Most Keycloak SSO incidents come from the seams between Keycloak and the applications that trust it: loose redirect URIs, shared secrets, stale signing certificates and tokens that carry more than the consumer needs. The cards below cover the integration-level controls to review for each client, token and SAML relationship. General platform hardening is covered in the security hardening guide.
Exact redirect URI matching
Register every OpenID Connect client with the full callback URLs it uses, and avoid wildcards in production. A wildcard such as a path prefix or subdomain pattern lets an attacker who controls one page receive authorization codes. Review each client's valid redirect URIs and web origins during every release, and confirm that development URLs are not carried into the production realm.
PKCE for public clients
Single-page applications and native mobile apps cannot keep a client secret, so they should use the authorization code flow with PKCE enabled on the client. Check that each public client requires a code challenge and that the implicit flow is disabled. Confirm this behavior in your own environment after each client change, because a client configured without PKCE still works and will not show an error.
Client secret storage and rotation
Confidential clients authenticate with a secret that should live in each application's own secret store, such as a vault, orchestrator secret or cloud key service, and never in source control or a shared configuration file. Agree a rotation procedure with each application team, including how old and new secrets overlap during the change. Ask who owns each secret and how a leaked secret is revoked.
SAML signing and encryption certificate lifecycle
SAML trust depends on the signing certificate Keycloak uses and the certificates each service provider holds. Track expiry dates for each certificate, plan overlapping rollover, and confirm that service providers refresh Keycloak metadata or receive the new certificate before cutover. Where assertions are encrypted, record which keys decrypt them and who controls them. Test the rollover on a non-production client first.
Metadata refresh for SAML consumers
Service providers that pull identity provider metadata must refresh it on a schedule and reject metadata that no longer matches the current realm configuration. Document where each consumer gets its metadata, how often it reloads, and what happens when a certificate changes. Metadata URLs should be served over TLS from the same host the service provider already trusts, so that an attacker cannot substitute a different key.
Audience and issuer validation in APIs
APIs that accept Keycloak access tokens should check the issuer, the expected audience and the token signature against the realm's keys, and reject tokens issued for other clients. A token that is valid for the web app may not be valid for the payments API. Ask each API team to show the validation rules in their code and test a token from another client to confirm it is refused.
Avoiding over-broad roles in tokens
Realm and client roles placed into tokens should match what each consumer needs, not the full set of roles a user holds. Use client scopes to limit which roles and claims each client receives, and review mappers that add group or role claims by default. Broad role claims can be copied into logs, caches and downstream services, so review them with the same care as access grants.
Separate admin and public hostnames
The Keycloak production guide advises exposing the admin console and Administration REST API on a different hostname or context path from public frontend URLs. Confirm that the reverse proxy routes administrative paths only from approved networks and that application clients never receive admin hostnames. Agree this split with your network team before go-live, since changing hostnames later affects issuer values in every token.
TLS on all communication
Keycloak's production guidance calls for TLS on all communication, including browser traffic, back-channel calls from applications, database connections and SMTP. Check that issuer and metadata URLs use HTTPS, that certificates are renewed before expiry, and that clients validate the certificate chain instead of disabling verification. Record which connections support plaintext today so they can be closed in the rollout plan.
How to test Keycloak SSO integration and confirm it fails safely
Before any application goes live on Keycloak, write a test plan for each client that proves two things: sign-in works for legitimate users, and every failure path denies access instead of granting it. The plan should list each application, each protocol it uses (OpenID Connect or SAML 2.0), and the realm and client settings it depends on. Testing against a single generic login is not enough, because a client registered with the wrong settings can still complete a sign-in while leaking access it should not grant. Assign one owner per client so that results can be traced back to a specific configuration.
Start with the happy path from a clean browser session for each application and protocol. Confirm first login, including any required actions such as password change or MFA enrollment. Then confirm silent sign-in: with one web app already signed in, open a second web app registered in the same realm and check that it signs the user in without a password prompt. Repeat with the browser fully closed and reopened to see whether the session behaves as your token and session settings intend. Record which claims arrive in each token or SAML assertion, because later checks depend on them.
Decode the test tokens and SAML assertions and check them field by field. For OpenID Connect, verify that the issuer matches the realm URL your applications are configured with, that the audience (aud) names the API or client that will consume the token, that the expiry (exp) matches the lifetime you chose, and that roles, groups and mapped attributes appear in the expected claims. For SAML, check the Issuer, the Audience restriction, the NotOnOrAfter condition and the attribute statements. Mismatches in any of these fields are the most common cause of intermittent production failures, so treat each one as a defect until explained.
Run the negative tests next, and expect each one to be rejected. A login request with a redirect URI that is not registered on the client must fail at Keycloak. A token issued for one API must fail when presented to a different API, which means the resource server must check the audience itself rather than trusting that any valid token from the realm is acceptable. Disable a test user and confirm that existing sessions and new sign-ins both stop working within the window you have documented. Present an expired token and a tampered token (with an edited payload and an unchanged signature) and confirm that validation fails. Finally, sign out of one application and confirm which other sessions end. Logout behavior varies by protocol and client settings, so compare results against your written expectation and confirm the backchannel logout behavior with your team before go-live.
Confirm that each application fails closed when Keycloak is unreachable. Stop or block access to the Keycloak endpoints in a test environment and check that the application refuses new sessions and does not fall back to a local or cached login. Check how already-issued tokens are handled, and confirm that the application shows a clear error rather than an empty or anonymous page. Before go-live, build a staging realm with production-like clients, redirect URIs and token settings, run the full test plan there, and export the realm configuration. Compare that export with the production configuration as a diff and resolve every unexpected difference before the change is promoted. Confirm with your Keycloak administrators which export format and tooling your team will use.
What to monitor, back up, change and document after SSO go-live
This table lists the recurring work that keeps a Keycloak SSO integration safe after launch, with the area, the concrete tasks and the role that owns each one. Read it as a handover checklist: each row should have a named owner and a scheduled review before go-live. The main takeaway is that most post-launch failures come from unreviewed redirect URIs, expired certificates, untracked mapper changes and upgrades applied without reading the notes, so those rows need the most discipline.
| Area | What to do | Who owns it |
|---|---|---|
| Client inventory and redirect URIs | Keep a register of every client, its protocol, owner and redirect URIs. Review it on a fixed schedule and remove clients for retired applications. | Identity team with application owners |
| Secrets and SAML certificates | Track client secrets, signing and encryption keys and SAML certificates with their expiry dates. Plan renewal and cutover before each expiry and confirm each relying party accepts the new certificate. | Identity team and application owners |
| Realm configuration as code and backups | Export realm configuration as code on each approved change and back it up together with the database. Test restores in a non-production environment so the export and database stay in step. | Identity platform engineers |
| Login failures and token errors | Enable metrics on the management interface and review login failures, token errors and latency. Confirm which signals your environment exposes, and leave Prometheus scraping and alert routing to the monitoring topic. | Platform operations, with identity team review |
| Upgrades and upgrade notes | Read the upgrade notes before each minor release and test client behavior, especially token claims and logout, in a staging realm. Keycloak plans four minor releases a year, so schedule a recurring review against that cadence. | Identity platform engineers with change board approval |
| Mapper and scope changes | Log every protocol mapper, client scope and role or group mapping change as a change record with the reason, approver and rollback step. | Identity team, approved by the security owner |
| Application onboarding checklist | Use a standard checklist covering protocol choice, redirect URIs, token lifetimes, required claims, logout behavior and test sign-in before the client is enabled. The identity team signs off each application before production access. | Identity team sign-off, application owner completes |
Questions buyers ask about Keycloak SSO integration
How much does Keycloak SSO integration cost?
Cost follows from the written scope, and DeployOpen does not publish a price list. The main one-time components are discovery and planning, realm and client setup, claim and role mapping, testing across environments, cutover support and handover documentation. Each application adds work because redirect URIs, token settings and mappings differ per client. Recurring costs include the infrastructure that runs Keycloak, such as compute, a supported production database, load balancing and monitoring, which is usually paid to your cloud provider or hardware team. Upgrade testing and any support retainer also recur. Costs rise with the number of applications, a mix of SAML and OpenID Connect, directory integration, high availability design and the number of environments. When you request a quote, ask for line items split into one-time and recurring costs, the assumptions behind each, and what is excluded.
How long does it take to integrate applications with Keycloak?
The duration depends on how many applications you connect, which protocols they use, and how many environments must be covered before production. One OpenID Connect web application in a single environment is a much smaller project than twenty applications across development, test and production, with SAML service providers and custom claims. This page does not give a timeline because the answer depends on your written inventory. Ask for a schedule that lists the phases, the application batches and the dependencies on application owners, network changes and certificate approvals. Most timing risk sits in waiting for owner decisions and environment access rather than in the Keycloak configuration itself. Agreeing the inventory first lets both sides plan with fewer assumptions, and a fixed scope gives you deliverables you can check before work starts.
Can our own team integrate applications with Keycloak alone?
Yes, if your team has the skills and the inputs. Internal staff can usually handle the Keycloak side, including creating realms and clients, setting redirect URIs and token lifetimes, and mapping roles and groups to claims. The application side is where skills matter most. Each application must validate tokens correctly, checking the issuer, audience, signing keys, expiry, and state or nonce values, and it must handle logout and session refresh. Teams new to this work should start with one low-risk application and use a documented reference implementation. Before starting, write an inventory covering each application, its protocol, owner, redirect URIs, required claims and test accounts. Without that inventory, most projects stall on questions that could have been answered on day one. A pilot will show whether your team's skills cover the rest of the estate.
What does Keycloak SSO integration need from our team?
The main inputs are decisions and access, not Keycloak expertise. Application owners confirm the sign-in protocol, the redirect and logout URIs for each environment, and the claims or roles the application reads. Your identity team approves the realm layout, the group structure and which users may sign in to which application. Certificate contacts provide or approve TLS certificates for the Keycloak hostname and the signing and encryption keys used with SAML. Test accounts covering standard users, administrators and users with restricted roles let you verify each flow before cutover. Network and DNS owners open the paths between browsers, applications and Keycloak. Production change windows must be agreed in advance. Name one decision owner, because most delays come from unanswered questions. Ask that these inputs appear in the written scope so each one has an owner and a due date.
Is SAML harder to integrate than OpenID Connect in Keycloak?
SAML usually takes more setup work, but it is not harder in every case. The extra work is metadata and certificate handling. Each SAML service provider needs its entity ID, assertion consumer service URL and signing or encryption certificates exchanged through metadata, and those certificates expire and must be rotated on a schedule. Attribute names and NameID formats must match what the application expects, which usually requires testing against the application's own configuration. OpenID Connect builds on the OAuth 2.0 authorization flow, with client registration, redirect URIs, PKCE for public clients and JSON Web Tokens validated against the issuer's keys. The trust models differ. SAML relies on signed XML assertions delivered through the browser, while OpenID Connect separates the browser redirect from token retrieval. Choose based on what each application supports, and budget more time for SAML certificate lifecycle work.
Does DeployOpen issue audit reports or attestations for SSO?
No. DeployOpen prepares configuration, documentation and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports, attestations and certifications. For an SSO integration, the evidence package typically includes realm and client configuration exports, access and role mapping documentation, TLS and certificate records, test results for sign-in and logout flows, and change records for the production cutover. Keycloak event logging and admin event records can support the audit trail once they are configured and retained according to your policy. Ask your assessor which artifacts they need before work starts, so the deliverables match the controls they will test. Confirm log retention periods and who can access the logs with your own compliance team, because those decisions belong to your organization.
What is the difference between SSO integration and identity brokering?
SSO integration connects your applications to Keycloak so they trust Keycloak as the sign-in authority. Identity brokering covers external identities: Keycloak accepts sign-in from another OpenID Connect or SAML identity provider, or from a social login, and then issues its own tokens to your applications. Brokering adds first-login flows, account linking and attribute mapping, which a plain application integration does not need. Many projects need both, and they can be scoped separately. Brokering is covered in its own topic on this site. For planning, ask whether any application must accept users from outside your directory. If it must, brokering decisions affect claim design and user onboarding, so settle them before finalizing client configuration.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates and documents self-hosted open-source platforms inside your own infrastructure, so Keycloak runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.
How we scope
- Written scope lists each OpenID Connect and SAML 2.0 application, its client type and redirect URIs.
- Scope records realm layout, directory integration, role and group mapping, and the database and high availability design.
- Fixed-scope engagements agree deliverables and timelines in writing before any build work starts.
How we build
- Client registrations, token lifetimes and session settings are configured and recorded for repeatable promotion between environments.
- Role and group mappers are tested with sample users from each directory or identity broker before go-live.
- Login, token and logout paths are verified over TLS, including backchannel logout token signature validation.
How we hand over
- Documentation covers realm and client inventory, mapper logic, environment differences and the admin console access model.
- Handover records confirm the admin console and Administration REST API sit on a separate hostname or path from public URLs.
- Your team receives runbooks for upgrades, database migration choices and operator update approval settings.
How we support
- Retainers cover ongoing support, upgrades and continuous testing after go-live, agreed in writing.
- Upgrade work reviews each release's upgrade notes for behavior changes before realms move to a newer version.
- Metrics exposed on the management interface, with alerts on login failures and latency, can be set up in the engagement.
