Security Hardening
This guide covers essential security configurations to harden a production Keycloak deployment. These settings protect against common attack vectors including brute force, token theft, and misconfigured redirects.
TOC
Brute Force DetectionEnable Brute Force DetectionAdmin Endpoint ProtectionRestrict Admin Access via Network PolicySeparate Admin and Public HostnamesRedirect URI ValidationBest PracticesClickjacking ProtectionConfigure HeadersToken SecurityLimit Token ScopeAudience RestrictionToken LifespanEnable Refresh Token RotationSSL/HTTPS EnforcementCSRF ProtectionRead-Only User AttributesVault Integration for SecretsKubernetes Secrets VaultSecurity ChecklistBrute Force Detection
Keycloak can automatically detect and block brute force login attacks.
Enable Brute Force Detection
- In the Admin Console, go to Realm Settings > Security defenses > Brute force detection tab.
- Enable Permanent lockout or Temporary lockout.
- Configure the parameters:
- Click Save.
Temporarily locked users are automatically unlocked after the wait period. Permanently locked users must be manually re-enabled by an administrator in the user's detail view.
Admin Endpoint Protection
The Keycloak Admin Console and Admin REST API should be restricted to authorized networks.
Restrict Admin Access via Network Policy
Create a Kubernetes NetworkPolicy to limit access to the admin endpoints:
Network policies require a CNI plugin that supports them (for example, Calico, Cilium). Verify your cluster's CNI supports NetworkPolicy enforcement.
Separate Admin and Public Hostnames
Keycloak supports configuring separate hostnames for the admin console and public-facing endpoints:
This allows the admin interface to be served on an internal-only hostname.
Redirect URI Validation
Misconfigured redirect URIs can lead to open redirect vulnerabilities and authorization code interception.
Best Practices
- Never use wildcards (
*) in production redirect URIs. Use exact paths. - Register only the specific callback URLs your application uses.
- Avoid registering
localhostURIs in non-development environments.
Clickjacking Protection
Keycloak sets the X-Frame-Options and Content-Security-Policy headers to prevent clickjacking attacks.
Configure Headers
- Go to Realm Settings > Security defenses > Headers tab.
- Configure:
- Click Save.
Token Security
Limit Token Scope
Use Client Scopes to restrict the claims included in tokens to only what each application needs. Avoid granting all scopes by default.
Audience Restriction
Configure the Audience claim in access tokens to limit which resource servers accept the token:
- In the client's Client scopes > dedicated scope, add an Audience mapper.
- Set the Included Client Audience to the specific resource server client.
- Resource servers should validate the
audclaim matches their own client ID.
Token Lifespan
Minimize token lifespans to reduce the window of exposure for stolen tokens:
Enable Refresh Token Rotation
When enabled, each refresh token can only be used once. A new refresh token is issued with each token refresh request.
- Go to Realm Settings > Tokens tab.
- Enable Revoke Refresh Token.
- Set Refresh Token Max Reuse to
0(single use).
SSL/HTTPS Enforcement
- Go to Realm Settings > General tab.
- Set Require SSL to:
external requests— Requires HTTPS for all external connections (recommended).all requests— Requires HTTPS for all connections including internal.none— No SSL requirement (development only).
For TLS configuration, see Configure Ingress and TLS.
CSRF Protection
Keycloak includes built-in CSRF protection for the Admin Console and Account Console. No additional configuration is required.
For custom themes or forms, ensure that all form submissions include the ${_csrf.token} hidden field provided by Keycloak's template engine.
Read-Only User Attributes
Certain user attributes should be protected from modification by end users:
- Go to Realm Settings > User profile tab.
- For sensitive attributes, set Who can edit to
Adminonly. - Common attributes to protect:
email_verified,phone_number_verified, custom administrative flags.
Vault Integration for Secrets
Keycloak supports loading sensitive values (such as LDAP bind credentials, SMTP passwords, and IdP client secrets) from external vault sources instead of storing them in the database.
Kubernetes Secrets Vault
In the Kubernetes Operator deployment model, Keycloak can resolve secrets from Kubernetes Secrets via the KeycloakRealmImport CR's spec.placeholders field. See Manage Realms for usage.
For realm-level secrets configured via the Admin Console, use the vault syntax ${vault.<key>} in secret fields. The Kubernetes Secrets vault provider resolves keys from files mounted in the Pod.
Integration with external vault systems (such as HashiCorp Vault) may require a custom vault SPI provider. The availability and configuration of external vault providers depends on your Keycloak version and custom extensions. Refer to the upstream Keycloak documentation for the latest vault SPI options.