Keycloak Deployment Auditing – General Scope and Guidelines

Practical lessons from auditing multi-realm, multi-client Keycloak environments in medium and large organizations

1. Introduction

In medium and large enterprises, Keycloak deployments rarely follow a simple “one realm – one application” pattern. In reality, such environments typically consist of multiple realms reflecting organizational structures, environments, or business domains, alongside dozens or even hundreds of client applications.

These clients often include web frontends, backend services, machine-to-machine integrations, and legacy systems, all maintained by different teams with varying levels of IAM expertise. As a result, Identity and Access Management quickly becomes a shared responsibility rather than a centrally controlled component.

“A Keycloak audit is not about verifying settings in the admin console — it is about understanding how identity, applications, and security decisions interact at scale.”

The primary goal of a Keycloak deployment audit is therefore not to “find flaws in Keycloak itself”, but to assess whether the entire authentication and authorization ecosystem is secure, coherent, and aligned with modern OAuth 2.1 and OpenID Connect best practices.

From our experience auditing complex enterprise IAM landscapes, a comprehensive Keycloak security audit focuses on three complementary objectives:

- evaluating the configuration of the Keycloak Authorization Server,
- reviewing how client applications integrate with Keycloak,
- identifying security risks emerging from the interaction between both sides.

This holistic approach is essential, as many real-world security issues do not stem from a single misconfiguration, but from subtle inconsistencies across multiple realms, clients, and applications.

OVERALL RISK SEVERITY (ORS) MODEL

ORS
Impact	HIGH	Medium	High	Critical
	MEDIUM	Low	Medium	High
	LOW	Note	Low	Medium
		LOW	MEDIUM	HIGH
	Likelihood

To prioritize findings in a meaningful and actionable way, audit results are typically classified using a risk-based approach inspired by OWASP methodologies. Each finding is evaluated as a combination of:

- likelihood of exploitation,
- potential impact on confidentiality, integrity, and availability.

This allows organizations to distinguish between:

- critical risks with immediate business impact,
- medium and low risks related to configuration hardening and attack surface reduction,
- best-practice recommendations aimed at long-term security maturity.

Keycloak-side audit – known patterns, real-world consequences

Configuration aspects of Keycloak itself are well documented and widely discussed in official documentation and community guidelines. Nevertheless, real-world audits of large-scale deployments consistently reveal recurring issues such as:

- lack of regular realm key rotation,
- missing client secret rotation,
- overly permissive redirect URIs and web origins,
- unused but enabled service accounts,
- globally enabled “full scope allowed” settings,
- deprecated direct access grants left active,
- missing or inconsistent enforcement of PKCE.

While these topics are well known, they are worth revisiting from an operational perspective. In large, multi-realm Keycloak deployments, even seemingly minor configuration oversights can accumulate and significantly increase the overall attack surface.

2. Client-side audit – where the highest risks emerge

From a security standpoint, the most sensitive and often underestimated part of a Keycloak deployment is the client application layer. Even a well-configured Authorization Server cannot compensate for insecure client-side implementations.

“In real-world Keycloak deployments, the most critical security risks rarely originate in the IAM platform itself — they emerge at the client application layer.”

In practice, the most severe findings during Keycloak audits are almost always related to how applications consume tokens, validate authentication state, and handle sensitive data after a successful login.

Missing token validation in client applications

One of the most critical issues observed in enterprise environments is incomplete or missing access token validation on the application side. This includes scenarios where:

- endpoints do not verify authentication at all,
- token signatures or claims are not fully validated,
- authorization checks are inconsistently applied across APIs.

Such vulnerabilities effectively bypass Keycloak entirely, allowing attackers to interact directly with application endpoints without compromising the IAM platform itself.

Insecure token storage and handling

Another high-impact issue involves improper handling of access tokens within client applications. Common anti-patterns include:

- storing tokens in cookies without Secure or HttpOnly flags,
- persisting tokens in local or session storage,
- sharing tokens across application components in a durable form.

In browser-based applications, these practices dramatically increase exposure to XSS attacks and session hijacking. From an architectural perspective, this is an application design flaw rather than a Keycloak configuration issue.

Token transmission via URLs

Despite being widely discouraged, access tokens are still occasionally transmitted through URL query parameters or redirects, especially in legacy systems. This practice poses a severe security risk, as tokens may be exposed through:

- browser history,
- server and proxy logs,
- monitoring and analytics tools,
- third-party integrations.

In multi-application IAM environments, such leakage can have cascading effects across multiple systems.

Incomplete PKCE or nonce support

Some client applications technically use the Authorization Code Flow, but fail to:

- properly implement PKCE,
- validate nonce values,
- or explicitly enforce secure defaults in client libraries.

In complex deployments with numerous redirect paths and client types, this significantly increases the risk of authorization code injection attacks, even when Keycloak itself is correctly configured.

Missing security headers and improper cookie configuration

Finally, many audited applications lack basic web security hardening measures such as:

- Content-Security-Policy (CSP),
- HTTP Strict Transport Security (HSTS),
- properly configured SameSite cookie attributes.

These controls are not managed by Keycloak, yet they play a crucial role in protecting authentication flows and user sessions at the application level.

Summary

Auditing a Keycloak deployment in an enterprise environment requires looking far beyond realm and client configuration screens. While proper Keycloak hardening is essential, the highest security risks typically arise from insecure client-side implementations and architectural decisions.

“Keycloak can be hardened perfectly, yet the overall security posture will always be defined by the weakest client application integrated with it.”

Based on practical audit experience in large, multi-realm Keycloak environments:

- the most critical vulnerabilities emerge at the intersection of Keycloak and client applications,
- correct IAM configuration does not mitigate insecure application behavior,
- many high-impact issues can be resolved without changes to Keycloak itself, by improving application architecture and integration patterns.

A well-executed Keycloak security audit helps organizations reduce attack surface, standardize IAM integrations, and safely scale their identity infrastructure across teams, environments, and business units.

In large organizations, Keycloak effectively becomes the backbone of digital identity — and its real security strength is determined by the weakest link in the surrounding application ecosystem.