Keycloak Client Security Checker
Paste a Keycloak client or realm export and get a graded list of the settings that put your users at risk, from wildcard redirect URIs and missing PKCE to the password grant and unsigned SAML, each with the exact place in the admin console to fix it. All in your browser.
In the admin console: Clients → your client → Action → Export, or Realm settings → Action → Partial export with clients included. A client from GET /admin/realms/{realm}/clients/{id} or a full kc.sh export works too.
What the checker looks at
Each finding comes with a severity, a plain-English reason, where to change it in the admin console and what to change it to. The rules follow RFC 9700, the OAuth 2.0 Security Best Current Practice, and the Keycloak field names in a ClientRepresentation.
| Redirect URIs | *, whole-host and path wildcards, subdomain wildcards that never match, plain http://, localhost leftovers, and missing URIs. The same for post-logout redirect URIs, including what + inherits. |
| Web origins | *, plain http:// origins, wildcard origins that don't work, and what + carries over from the redirect URIs. |
| Grant types | Implicit flow, direct access grants (password grant), device authorization, CIBA, token exchange, and service accounts on public or mixed-use clients. |
| Client authentication | Public clients without PKCE S256, shared client secrets and their age, sender-constrained tokens, and legacy bearer-only clients. |
| Scopes and consent | Full scope allowed, offline_access as a default scope, offline access without consent, and microprofile-jwt defaults. |
| Lifespans | Client overrides for access tokens and client and offline sessions; with a realm export, realm token lifespans, refresh token rotation and offline session limits. |
| Client policies | With a realm export: which enabled policies cover each client for pkce-enforcer, reject-implicit-grant, reject-ropc-grant and secure-redirect-uris-enforcer, with conditions evaluated as Keycloak does, and "can't determine" where they depend on the request. |
| Logout | Missing back-channel or front-channel logout and logout URLs over plain HTTP. |
| SAML | Unsigned documents or assertions, client signatures not required, unencrypted assertions, SHA-1, Name ID format, ECP, IdP-initiated SSO and HTTP ACS URLs. |
The score starts at 100 and drops with each finding by severity; any critical finding caps it at an F. It is a quick read of the exported configuration, not a penetration test: it can't see your authentication flows or your applications' token handling. With a realm export, it also evaluates your client policies against each client and shows which ones enforce PKCE, reject the implicit and password grants, or check redirect URIs.
Fix it once, for every client
Fixing clients one by one doesn't stop the next one from being created with the same defaults. Most of the client-level findings can be enforced realm-wide with client policies: reject-ropc-grant, reject-implicit-grant, pkce-enforcer and secure-redirect-uris-enforcer. The RFC 9700 for Keycloak guide has a tested realm-wide profile. Token lifespans and refresh token rotation are covered in Tokens and Sessions.
Don’t forget the clients Keycloak creates for you. admin-cli ships with the password grant on, and its client ID is known to every attacker. See built-in clients and which Keycloak clients should be enabled when you go live.
Learn more
- Securing Keycloak in production — every common attack on a realm and the setting that addresses it.
- Keycloak “Invalid parameter: redirect_uri” — how redirect URI matching really works.
- Go-live checklist — everything to check before launch.
- JWT Decoder — inspect the tokens these clients issue.
Frequently asked questions
Is it safe to paste my client configuration here?
Yes. The checker runs entirely in your browser. Your JSON is never sent to Phase Two or any other server, logged, or stored. If the export includes a client secret or a SAML private key, the page replaces it with asterisks as soon as you paste, and it never appears in the report or the suggested fixes. You can confirm there are no network requests in your browser's developer tools.
How do I export a Keycloak client?
In the admin console, open Clients, select the client, and choose Action → Export in the top right. That downloads the client as JSON, including its secret. To check every client at once, use Realm settings → Action → Partial export with clients included; Keycloak masks secrets in a partial export. A client from the Admin REST API (GET /admin/realms/{realm}/clients/{id}) or a full kc.sh export also works.
Why are wildcard redirect URIs dangerous in Keycloak?
A trailing * makes the redirect URI a prefix match, so Keycloak will deliver authorization codes to any URL that starts with it. If any page under that prefix is an open redirect or hosts user content, an attacker can capture codes. A bare * accepts any URL at all. RFC 9700 requires exact string matching. Note that Keycloak only supports * at the end of a URI: https://*.example.com never matches a real subdomain.
Does my public client need PKCE?
Yes. A public client, such as a single-page or mobile app, has no secret, so PKCE is the only thing that stops an intercepted authorization code from being redeemed by someone else. Turn on Require PKCE with the S256 method in the client's Capability config, and enforce it realm-wide with the pkce-enforcer client policy executor.
Should I turn off Direct access grants?
On almost every client, yes. Direct access grants (the OAuth password grant) let a client exchange a username and password for tokens without the browser login flow, so CAPTCHA, passkeys and most second factors don't apply. It is the first path credential-stuffing tools try, and admin-cli has it on by default. Move backend integrations to service accounts and reject the grant with a client policy.
What does Full scope allowed do?
With Full scope allowed on, a client's tokens carry every role the user has across the realm, not only the roles that application needs. Turning it off and adding only the needed roles to the client's dedicated scope limits what a leaked token can do. Test first, because an application that relies on a role you didn't add will lose access.
Can I apply the suggested fixes automatically?
The checker produces a fixed JSON and a diff for the changes it can make safely, such as turning off the implicit flow, requiring PKCE S256, or moving offline_access to an optional scope. It never invents redirect URIs, certificates or client authentication settings. Review the changes and try them in a test realm before applying them to production.
Does it understand realm client policies?
Yes. With a realm export, it evaluates each enabled client policy against each client the way Keycloak does: conditions are combined, negative logic and STRICT mode are honored, and each condition votes for the request the executor acts on. Supported conditions include any-client, client-access-type, client-type, client-roles (export with roles included), client-attributes, client-scopes and grant-type. When a condition depends on the request itself, such as an optional scope, or on who saves the client, the checker says it can't be determined instead of guessing.
Does it check SAML clients?
Yes. For SAML clients it checks that documents and assertions are signed, that client signatures are required, that assertions are encrypted, the signature algorithm, the Name ID format setting, ECP and IdP-initiated SSO, and the redirect URIs Keycloak uses to validate the Assertion Consumer Service URL.