bin/kc.[sh|bat] start --spi-connections-http-client--default--<configurationoption>=<value>Keycloak often needs to make requests to the applications and services that it secures. Keycloak manages these outgoing connections using an HTTP client. This guide shows how to configure the client, connection pool, proxy environment settings, timeouts, and more.
See Configuring trusted certificates for how to configure a Keycloak Truststore so that Keycloak is able to perform outgoing requests using TLS.
The HTTP client that Keycloak uses for outgoing communication is highly configurable. To configure the Keycloak outgoing HTTP client, enter this command:
bin/kc.[sh|bat] start --spi-connections-http-client--default--<configurationoption>=<value>The following are the command options:
Maximum time in milliseconds until establishing a connection times out. Default: Not set.
Maximum time of inactivity between two data packets until a socket connection times out, in milliseconds. Default: 5000ms
Size of the connection pool for outgoing connections. Default: 128.
How many connections can be pooled per host. Default: 64.
Maximum connection time to live in milliseconds. Default: Not set.
Maximum time an idle connection stays in the connection pool, in milliseconds. Idle connections will be removed from the pool by a background cleaner thread. Set this option to -1 to disable this check. Default: 900000.
Enable or disable caching of cookies. Default: true.
File path to a Java keystore file. This keystore contains client certificates for mTLS.
Password for the client keystore. REQUIRED, when client-keystore is set.
Password for the private key of the client. REQUIRED, when client-keystore is set.
Specify proxy configurations for outgoing HTTP requests. For more details, see Proxy mappings for outgoing HTTP requests.
If an outgoing request requires HTTPS and this configuration option is set to true, you do not have to specify a truststore. This setting should be used only during development and never in production because it will disable verification of SSL certificates. Default: false.
| Do not let outgoing retry duration exceed the caller’s timeout. Otherwise, the caller may time out and see an error while Keycloak continues retrying in the background. |
Keycloak can automatically retry failed outgoing HTTP requests. This is useful for handling transient network errors or temporary service unavailability. Retry behavior is disabled by default and must be explicitly enabled.
The following are the retry configuration options:
Maximum number of retry attempts for failed HTTP requests. Set to 0 to disable retries. Default: 0.
Retries for requests that have already been sent (for common methods such as GET and POST) are always enabled. Use max-retries to control whether retries are performed.
|
Initial backoff time in milliseconds before the first retry attempt. Default: 1000.
Multiplier for exponential backoff between retry attempts. For example, with an initial backoff of 1000ms and a multiplier of 2.0, the retry delays would be: 1000ms, 2000ms, 4000ms, etc. Default: 2.0.
Whether to apply jitter to backoff times to prevent synchronized retry storms when multiple clients are retrying at the same time. Default: true.
Jitter factor to apply to backoff times. A value of 0.5 means the actual backoff time will be between 50% and 150% of the calculated exponential backoff time. Default: 0.5.
bin/kc.[sh|bat] start --spi-connections-http-client-default-max-retries=3 \
--spi-connections-http-client-default-initial-backoff-millis=1000 \
--spi-connections-http-client-default-backoff-multiplier=2.0In this example, Keycloak will retry failed HTTP requests up to 3 times with exponential backoff starting at 1000ms and doubling with each retry attempt.
| Retry behavior applies to all outgoing HTTP requests made by Keycloak, including OCSP validation, identity provider communication, and other external service calls. |
To configure outgoing requests to use a proxy, you can use the following standard proxy environment variables to configure the proxy mappings: HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.
The HTTP_PROXY and HTTPS_PROXY variables represent the proxy server that is used for outgoing HTTP requests. Keycloak does not differentiate between the two variables. If you define both variables, HTTPS_PROXY takes precedence regardless of the actual scheme that the proxy server uses.
The NO_PROXY variable defines a comma separated list of hostnames that should not use the proxy. For each hostname that you specify, all its subdomains are also excluded from using proxy.
The environment variables can be lowercase or uppercase. Lowercase takes precedence. For example, if you define both HTTP_PROXY and http_proxy, http_proxy is used.
HTTPS_PROXY=https://www-proxy.acme.com:8080
NO_PROXY=google.com,login.facebook.comIn this example, the following results occur:
All outgoing requests use the proxy https://www-proxy.acme.com:8080 except for requests to google.com or any subdomain of google.com, such as auth.google.com.
login.facebook.com and all its subdomains do not use the defined proxy, but groups.facebook.com uses the proxy because it is not a subdomain of login.facebook.com.
An alternative to using environment variables for proxy mappings is to configure a comma-delimited list of proxy-mappings for outgoing requests sent by Keycloak. A proxy-mapping consists of a regex-based hostname pattern and a proxy-uri, using the format hostname-pattern;proxy-uri.
For example, consider the following regex:
.*\.(google|googleapis)\.comYou apply a regex-based hostname pattern by entering this command:
bin/kc.[sh|bat] start --spi-connections-http-client--default--proxy-mappings='.*\\.(google|googleapis)\\.com;http://www-proxy.acme.com:8080'The backslash character \ is escaped again because micro-profile config is used to parse the array of mappings.
To determine the proxy for the outgoing HTTP request, the following occurs:
The target hostname is matched against all configured hostname patterns.
The proxy-uri of the first matching pattern is used.
If no configured pattern matches the hostname, no proxy is used.
When your proxy server requires authentication, include the credentials of the proxy user in the format username:password@. For example:
.*\.(google|googleapis)\.com;http://proxyuser:password@www-proxy.acme.com:8080# All requests to Google APIs use http://www-proxy.acme.com:8080 as proxy
.*\.(google|googleapis)\.com;http://www-proxy.acme.com:8080
# All requests to internal systems use no proxy
.*\.acme\.com;NO_PROXY
# All other requests use http://fallback:8080 as proxy
.*;http://fallback:8080In this example, the following occurs:
The special value NO_PROXY for the proxy-uri is used, which means that no proxy is used for hosts matching the associated hostname pattern.
A catch-all pattern ends the proxy-mappings, providing a default proxy for all outgoing requests.