Keycloak Deployment Auditing – General Scope and Guidelines

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.