Razvan Tufisi

The day a Keycloak realm is reachable from the internet, automated scanners find it. They read /realms/<name>/.well-known/openid-configuration, try every client ID that ships with every realm against the token endpoint and the login pages, and start replaying username and password pairs leaked from other sites. The traffic arrives from a different residential IP on almost every request, so it looks nothing like one noisy attacker. What you are trying to stop is not a single brute-force run. It is account takeover through credential stuffing, plus the enumeration that tells an attacker which of your users exist.

So the go-live question is not "should I disable admin-cli?" It is "which clients, and which grant types, should be on at all?" The short answer: the password grant off on every client, enforced by policy; only the clients you actually use exposed; a CAPTCHA on every flow that renders a login page; and account left enabled. Disabling a client is one tool among several, and for account it is usually the wrong one.

Everything below was reproduced against Keycloak 26.8.1, and every error string is copied out of a real response.

Today we're launching keycloak-skills — an open-source Agent Skills plugin that teaches Claude how to configure Keycloak correctly — and the Phase Two Keycloak MCP server, 158 admin tools that let it do the work against a live cluster instead of just telling you what to type.

Two commands to install. Works against any Keycloak — and gets sharper the closer you get to ours. Don't have a Keycloak yet? The agent can provision one for you and it's free for 30 days.

We're open-sourcing keycloak-atomic-auth-flows, a Keycloak extension that replaces an entire set of authentication flows, authenticator configs, and their bindings in one atomic, transactional request.

It was built in partnership with Gusto, who use Keycloak for user authentication and rely on Phase Two for enterprise Keycloak support. It has been running in their production environment for almost a year. The public repository is the extraction of that work into a standalone extension anyone can install.

IdP Initiated Flow​

When implementing SAML for the establishment of an Identity Provider, two primary options are available:

1. Service Provider (SP) initiated
2. Identity Provider (IdP) initiated

The SP initiated flow is widely recognized by users due to its straightforward configuration, which is merely the exchange of some metadata. In contrast, the IdP-initiated flow is less intuitive and involves an additional step that may not be readily apparent to many users. The purpose of this blog is to elucidate the steps necessary to successfully execute the IdP-initiated flow. We will setup a full example

A fundamental understanding of SAML 2.0 and Keycloak is required to effectively follow the provided instructions.