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.

The Keycloak User Group UK is holding its first meetup on Friday 20 November, 1–5pm, at London Bridge Hive — 8 Holyrood Street, London. Phase Two is sponsoring it, and we would like you there. It is a few short talks, some hands-on workshops, and an open discussion, followed by beers at Nine Lives from 5pm.

RSVP here. It is free, and the form is the only place that counts — see below.

A Keycloak infinite redirect loop at login almost always means one thing: a cookie Keycloak set on the way to the login page did not come back on the way out of it. Keycloak has no session to resume, so it starts the flow again, and the browser bounces between your application and /protocol/openid-connect/auth until it gives up.

The reason this is so common is in the Set-Cookie headers. Keycloak 26.8.0 marks every cookie in the login flow Secure; SameSite=None, unconditionally — there is no setting that relaxes it. A browser will not store a Secure cookie that arrives over plain http://, and it will not store SameSite=None without Secure. So the loop is usually not an OIDC problem at all. It is a transport problem that the OIDC layer reports as a lost session.

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.

Migrating from Auth0 to Keycloak is three separate jobs wearing one name. Profiles move easily — Auth0's export job gives you newline-delimited JSON and Keycloak's partial-import endpoint takes it. Passwords do not move at all: Auth0 hashes with bcrypt, Keycloak 26.7.4 ships four password-hashing providers and none of them is bcrypt, so you either reset every password or stand up a bridge that verifies against the old hashes on first login. Your Rules and Actions have to be rewritten, because there is no equivalent runtime — some of them become authentication-flow configuration with no code at all, and some become a Java SPI.

The part that costs people a weekend is none of those. It is that Keycloak's admin API answers 201 Created to three different malformed migrations and then quietly loses the data. Everything below was run against Keycloak 26.7.4 on PostgreSQL 16.

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.

A Keycloak 403 Forbidden always means the same thing: your token was accepted, and the permissions attached to it were not enough. That is the whole difference from a 401, which means the token itself was rejected — missing, expired, malformed, or signed by another realm. Checking which of the two you have is the fastest useful thing you can do, because 401 sends you to the token and 403 sends you to role mappings, and they share no fixes.

After that, the question is which surface returned it. The Keycloak admin console, the Admin REST API and your own application all return 403 for unrelated reasons, and the response body tells you which one you are looking at without any further digging.

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.

A JWKS — JSON Web Key Set — is a JSON document containing a list of public keys, each encoded as a JWK (JSON Web Key). Its purpose is to let anyone verifying a signed token fetch the right public key over HTTP instead of having it configured by hand. The token names the key it was signed with in its kid header; the verifier looks that kid up in the set.

That is the whole idea, and it buys one specific thing: the signer can change keys without anyone who verifies its tokens changing configuration. Everything else about JWKS — the field names, the caching, the rotation ordering — follows from that.

This post covers what is actually in a JWK, where the JWKS URL comes from, what Keycloak publishes and what it deliberately does not, and the two directions the traffic flows in. Every number and every error string below came from a real run.

We're shipping an experimental Telemetry Export for Enterprise Keycloak clusters. Point it at your own OTLP endpoint and your cluster's Keycloak logs and authentication events start arriving in whatever you already run — OpenSearch, Datadog, Grafana, SigNoz, Elastic, or your own OpenTelemetry Collector.

No agent to install, no log shipper to configure, and nothing to run on your side except the collector you already have.