17 posts tagged with "security"

Data residency requirements for a SaaS authentication service are not one requirement, they are four, and only the first of them is about a region. You have to name where each class of identity data is stored. You have to name a lawful transfer mechanism for every touchpoint outside that region, including remote administrative access, which is a transfer and not an exception to one. You have to hold Article 28 processing terms that say so in writing. And you have to be able to produce an inventory of where the identity data goes after it is stored — the brokers, mail relays, event listeners and relying parties your own realm sends it to. Below is the checklist a data protection officer sends, the document that answers each item, what a thin answer looks like, our own answers including the unflattering ones, and the commands that generate that fourth item from a running Keycloak realm, tested on 26.8.1.

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.

Every second a customer spends on your login page is a second they might spend somewhere else. Typing an email and password, mistyping it, waiting for a code, switching to an authenticator app, or giving up and resetting the password are all time between someone deciding to sign in and actually getting in. Passkeys remove most of those steps, and every large published measurement shows the same result: sign-in with a passkey takes about half the time, or less, and fails far less often. Our own customers report the same: after introducing passkeys, they measured login times drop by several seconds per sign-in.

This post collects the published figures, explains where the time goes, and shows how to introduce passkeys in Keycloak alongside the password login you already have.

The login page is the most attacked page on an online store, and it is rarely the one anyone designed for attack. Homegrown e-commerce login usually starts as a users table, a bcrypt column and a session cookie, and it grows a password reset, a mobile API, a trade-account flag and a social button over the years. What it almost never grows is a defense against credential stuffing: automated replay of email and password pairs leaked from other sites, aimed at whichever of your customers reused one. Replacing homegrown login with Keycloak gives a store one identity service for web, app and back office, with social login, B2B accounts and branded pages built in, and you can move customers onto it without asking anyone to reset a password. It does not make the login page safe on its own. The defaults leave doors open that attackers look for first, and the rest of this post covers both halves: what you gain, and what has to be layered on top.

Data residency is a statement about geography: your identity data is stored and processed in a named region and does not leave it. Data sovereignty is a statement about law and control: which legal systems can compel access to that data, and who holds the keys and the administrative credentials that make access technically possible. They are not the same claim, and the gap between them matters more for an identity provider than for almost any other system you run, because the IdP holds a record of every person who can sign in to anything you operate and a log of when and from where they did it. Below: both definitions, each applied to the four classes of data a Keycloak realm actually stores, the point where a region setting stops helping — demonstrated against Keycloak 26.8.1 — and the rubric European buyers have started scoring vendors with.

Bottom line: upgrade this week if you broker SAML, rely on mTLS token binding, or skip OTP by header; otherwise take it next cycle. Keycloak 26.8.1 fixes 19 CVEs — 18 in Keycloak, all medium or low, plus one high-severity jackson-databind issue. The fix most likely to move your schedule has no CVE — an item filed under Weaknesses that upstream describes as unauthenticated login as an arbitrary user through the SAML broker.

Bottom line: not urgent — plan it, don't rush it. Keycloak 26.8.0 fixes seven CVEs, published as six medium and one low, none high or critical. Schedule it because SCIM, multi-cluster v2 and client secret rotation move from preview to supported, and brute-force lockouts now persist to your database by default.

Bottom line: upgrade this week if you are on 26.7. If you are on 26.6 or 26.4, the fixes are merged to your branch but nobody has tagged a release, so there is no build to take. Keycloak 26.7.5 fixes 14 CVEs: ten in Keycloak, none rated above medium (6.5), and four in bundled libraries, one of them critical. Three breaking changes, one of which changes what lands in your tokens.

Keycloak publishes releases and container images for the current minor version only. It does backport selected security fixes to the two most recent even-numbered branches, and it tags them — but it cuts no GitHub release and builds no image from those tags. As of today there are nine such tags on release/26.4 and three on release/26.6, containing fixes for CVEs that were announced months ago, that you cannot docker pull from anywhere upstream.

Phase Two now builds them. quay.io/phasetwo/keycloak:26.4.16 and quay.io/phasetwo/keycloak:26.6.7 exist today, built from the tag's own Dockerfile, and we intend to keep building the two previous minor lines alongside the current one for as long as upstream keeps backporting to them.

Bottom line: upgrade this week if your login page or SAML endpoints are reachable from the internet, or if you run stateless mode on MySQL/MariaDB. Otherwise take it in your normal cycle. Keycloak 26.7.4 fixes six CVEs — five published as high, one medium. Two of them let an unauthenticated attacker exhaust memory and crash the server by hitting endpoints that are open by definition. One breaking change, in Authorization Services URI matching.