20 posts tagged with "security"

Today we're releasing Login Tracer by Phase Two, a free Chrome DevTools extension for debugging SAML and OpenID Connect / OAuth logins. Open DevTools, select the Login Tracer panel, and log in: every SSO request in the tab is decoded, grouped into a login flow, and checked for common misconfigurations, with explanations of the Keycloak setting most likely behind each problem. It requests no permissions and makes no network requests.

Bottom line: upgrade now if Keycloak terminates or brokers SAML; within the week otherwise. Keycloak 26.8.2 fixes 33 CVEs. The one that should move your schedule is critical and needs no credentials — a signature bypass in the SAML HTTP-Redirect binding that upstream describes as leading to full account takeover of federated users. The harder problem is that 26 of the 33 have no published advisory yet, so most of this release carries no severity you can plan against.

The CLOUD Act does not hand anyone a key to a European data centre. It does something narrower, and for an identity provider more awkward than the usual telling. 18 U.S.C. § 2713 makes the location of data irrelevant to whether a provider under US jurisdiction has to produce it, and the process that reaches most of what an identity provider holds is the cheapest instrument in the Stored Communications Act: a subpoena for subscriber records, no warrant, no judicial finding, and no obligation to tell the customer. Below is what the statute says, which level of process reaches which table in a Keycloak realm (tested on 26.8.1), why the defence the CLOUD Act added does not cover an EU customer's identity data on either of its two conditions, and what a vendor with a US parent can honestly promise. Including us.

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.