Articles

Keycloak Production Hardening: Security Checklist (2026)

April 18, 2026 7 min read

Keycloak doesn’t actually enforce strong passwords by default, which is a massive security hole for many production deployments.

Here’s how to harden Keycloak for production, focusing on security best practices.

1. HTTPS Everywhere

Problem: Unencrypted traffic between clients and Keycloak, or between Keycloak nodes, exposes sensitive authentication data.

Diagnosis: Check if your Keycloak instances are accessible via http://. Look for http://your-keycloak-host:8080 or similar.

Causes & Fixes:

  • No Load Balancer/Proxy SSL Termination: Your load balancer or reverse proxy isn’t configured to handle SSL.
    • Diagnosis: Use openssl s_client -connect your-keycloak-host:443 -servername your-keycloak-host and check for certificate details.
    • Fix: Configure your proxy (e.g., Nginx, HAProxy, Apache) to terminate SSL. For Nginx, this involves listen 443 ssl; and ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;.
    • Why it works: The proxy handles the TLS handshake, encrypting traffic before it reaches Keycloak.
  • Keycloak Not Configured for HTTPS Directly (less common in prod): If not using a proxy, Keycloak itself needs to be configured.
    • Diagnosis: Check your Keycloak startup arguments or standalone.xml/standalone-ha.xml for https related settings.
    • Fix: For direct HTTPS, import your keystore into Keycloak’s truststore and configure the HTTPS listener. This is usually done via system properties like -Dkeycloak.https.keystore.file=/path/to/keystore.jks -Dkeycloak.https.keystore.password=password.
    • Why it works: Keycloak directly establishes a TLS connection with clients.

2. Strong Password Policies

Problem: Weak or easily guessable passwords allow unauthorized access.

Diagnosis: Log in to Keycloak as an administrator, navigate to Authentication -> Policies -> Password Policy for your realm, and inspect the current settings. Are they restrictive enough?

Causes & Fixes:

  • Default Password Policy: Keycloak’s default policy is often too permissive, allowing simple passwords.
    • Diagnosis: Check the Policy tab for your realm’s password policy. Default often has minimal requirements.
    • Fix: Configure a strong password policy. Navigate to Authentication -> Policies -> Password Policy, select your realm, and click Add Policy. Add policies like:
      • require-one-uppercase
      • require-one-lowercase
      • require-one-digit
      • require-one-special
      • minLength: 12 (or higher)
      • max-age: 90 (for password expiration)
      • no-reuse: 5 (to prevent reusing recent passwords)
      • disable-strong-passwords (Ensure this is not set, or set to false if it exists as a negative flag).
    • Why it works: Enforces complexity, length, and recency rules, making brute-force attacks significantly harder.
  • No Rate Limiting on Login: Brute-force attacks can try unlimited passwords without consequence.
    • Diagnosis: Observe login attempts in Keycloak logs. Are there any blocks after multiple failed attempts?
    • Fix: In Authentication -> Flows, select your realm, and edit the Login flow. Add a Brute Force Protection authenticator. Configure it with appropriate settings (e.g., Max failures: 5, Wait time: 300 seconds, Max login failures: 10).
    • Why it works: Temporarily locks out users or IP addresses after a certain number of failed login attempts, thwarting automated attacks.

3. Realm and Client Secrets Management

Problem: Default or weak secrets for realms and clients can be compromised, allowing attackers to impersonate clients or even realms.

Diagnosis: Review the realm encryption and client secret settings within the Keycloak admin console.

Causes & Fixes:

  • Default/Weak Realm Keys: Keycloak uses realm keys for encrypting sensitive data.
    • Diagnosis: In Realm Settings -> Keys, check the Realm Key and Realm IV values. If they are short or look like defaults, they might be weak.
    • Fix: For new realms, Keycloak generates strong keys. For existing realms, consider regenerating them if they are weak, but this can impact existing sessions. For production, ensure they are long and randomly generated. Keycloak automatically handles this during realm creation.
    • Why it works: Strong, unique keys make it computationally infeasible to decrypt sensitive data stored by Keycloak.
  • Weak Client Secrets: Client secrets are used by confidential clients to authenticate themselves to Keycloak.
    • Diagnosis: In Clients -> [Your Client] -> Credentials, check the client secret. Is it short, predictable, or has it been reused?
    • Fix: Generate a strong, random client secret. Click Regenerate Secret for confidential clients. Aim for secrets that are at least 32 characters long and use a mix of alphanumeric and special characters.
    • Why it works: A strong, randomly generated secret acts like a password for your application, preventing unauthorized applications from acting as your client.

4. Auditing and Logging

Problem: Without proper logs, it’s impossible to detect or investigate security incidents.

Diagnosis: Check Keycloak’s logging configuration and review recent log files for suspicious activity.

Causes & Fixes:

  • Insufficient Logging Level: Keycloak might be logging too little information to be useful for security analysis.
    • Diagnosis: Examine standalone.xml (or standalone-ha.xml for clustered setups) and look for the <subsystem xmlns="urn:jboss:domain:logging:..."> section. Check the verbosity of loggers, especially for org.keycloak.
    • Fix: Increase the logging level for security-relevant categories. For example, in standalone.xml, change level name="INFO" to level name="DEBUG" or level name="TRACE" for org.keycloak.events and org.keycloak.services. You might also want to set level name="WARN" or INFO" for org.keycloak.authentication and org.keycloak.storage.
    • Why it works: Captures more detailed information about authentication attempts, token issuance, and administrative actions, crucial for forensic analysis.
  • Logs Not Centralized or Protected: Logs are lost if the server is compromised or disks fail, or they are hard to analyze.
    • Diagnosis: Are logs written to local files only? Are they easily accessible by unauthorized users on the server?
    • Fix: Configure Keycloak to send logs to a centralized logging system (e.g., ELK stack, Splunk, Graylog) using a logging appender. Ensure log files on disk have restricted permissions.
    • Why it works: Centralized logging allows for easier aggregation, searching, and alerting on security events across multiple Keycloak instances, and protects logs from tampering.

5. Session Management

Problem: Long-lived sessions or insecure session handling can be exploited.

Diagnosis: Review Keycloak’s realm settings related to sessions and tokens.

Causes & Fixes:

  • Long-lived Refresh Tokens: Refresh tokens can be used to obtain new access tokens indefinitely, which is risky if compromised.
    • Diagnosis: In Realm Settings -> Tokens, check the Revoke refresh token setting and the Offline session idle and Offline session max timeouts.
    • Fix: Set a reasonable expiry for offline sessions. In Realm Settings -> Tokens, configure Offline session idle (e.g., 30 days) and Offline session max (e.g., 90 days). Also, consider enabling Revoke refresh token if your clients can handle re-authentication gracefully.
    • Why it works: Limits the window of opportunity for an attacker to use a stolen refresh token to maintain persistent access.
  • Insecure Direct Access Grants: Allowing direct access grants without proper client authentication can be a loophole.
    • Diagnosis: In Clients -> [Your Client] -> Settings, check the Direct Access Grants Enabled setting.
    • Fix: Disable Direct Access Grants (Direct Access Grants Enabled: OFF) for clients that do not explicitly require it. Use standard OAuth2 flows like Authorization Code flow instead.
    • Why it works: Prevents clients from directly exchanging username/password for tokens, forcing them through more secure, standard OAuth2 flows that involve client authentication.

6. Admin Console Access Control

Problem: Broad access to the admin console allows unauthorized users to make critical security changes.

Diagnosis: Review which users have the realm-admin role or equivalent administrative privileges.

Causes & Fixes:

  • Over-privileged Admin Users: Too many users have full administrative rights.
    • Diagnosis: In Users -> [User] -> Role Mappings, check assigned roles.
    • Fix: Grant administrative roles (realm-admin, offline-token, manage-users, etc.) only to necessary personnel. Use fine-grained roles where possible. For highly sensitive operations, consider implementing multi-factor authentication (MFA) for administrators.
    • Why it works: Limits the blast radius of a compromised administrative account by restricting its permissions and making it harder to gain unauthorized access to the console.
  • Admin Console Exposed Publicly: The admin console is accessible from the internet without IP restrictions or MFA.
    • Diagnosis: Can you access https://your-keycloak-host/auth/admin/ from an external network without VPN or specific IP whitelisting?
    • Fix: Use your reverse proxy or firewall to restrict access to the admin console URL (/auth/admin/) to trusted IP addresses or networks. Alternatively, integrate MFA for admin access using Keycloak’s own capabilities or external identity providers.
    • Why it works: Adds layers of security (network segmentation, MFA) to protect the most critical part of the Keycloak system.

The next error you’ll likely hit after fixing these is related to client registration policies or perhaps issues with specific identity brokering configurations if they weren’t properly secured.

Want structured learning?

Take the full Keycloak course →