Skip to main content
GR Patil
Phase Two

GR is the co-founder and CEO of Phase Two, and has been working on Keycloak for 10+ years, and running Phase Two for the past 6. A technology entrepreneur for 30 years, he was a founder at BrightRoll (sold to Yahoo! for $640M), an early engineer at Twitter, and founded or led several successful early-stage startups.

View all authors

Data residency requirements for SaaS authentication

· 16 min read
GR Patil
Phase Two

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.

What Azure AD B2C's end of sale actually means

· 10 min read
GR Patil
Phase Two

Azure AD B2C's end of sale means Microsoft stopped selling it to new customers on 1 May 2025 and committed to supporting it until at least May 2030. It is not being shut down. Existing customers keep their tenants, can still create new ones, and keep the SLA, the security updates and the compliance posture. What ended is the roadmap.

One other date is doing a lot of damage. Premium P2 was discontinued on 15 March 2026 for all customers, and tenants moved to P1. That is a pricing-tier retirement, not a tenant retirement — but it has been reported often enough as "B2C shuts down in March 2026" that it is worth saying plainly: your tenant is fine, and you have roughly four years to make a decision rather than four months to execute one.

Four years is enough time to make a good decision and short enough that the one you make now is the one you live with. Here is what the three realistic destinations actually cost.

Keycloak 502 Bad Gateway behind a reverse proxy

· 8 min read
GR Patil
Phase Two

A Keycloak 502 Bad Gateway never comes from Keycloak. RFC 9110 defines 502 as a status a gateway emits about its upstream — so the proxy is telling you it could not get a usable response out of Keycloak, and the explanation is in the proxy's error log rather than anywhere in Keycloak's configuration. Start there, every time. In nginx there are only six lines that produce a 502 in front of Keycloak, each maps to one cause, and three of the six are the Quarkus-era port layout catching out a config written for an older release.

Everything below was reproduced against Keycloak 26.8.1 behind nginx 1.29, and every error string is copied out of a real run.

Data residency vs data sovereignty for your identity provider

· 14 min read
GR Patil
Phase Two

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.

Migrating from Okta to Keycloak

· 18 min read
GR Patil
Phase Two

Migrating from Okta to Keycloak is not a user migration. The users are the easy part: Okta's Users API hands you profiles and group membership, and Keycloak's partial-import endpoint takes them. Two other things decide how long this takes. Okta will not give you password hashes — they are an import-only field, so every user either resets a password or authenticates through Okta one last time while you drain. And every SAML and OIDC application has to be re-pointed by hand, one at a time, because the assertion consumer URL, the entity ID and the signing certificate all change when the identity provider does.

So the schedule is set by the app inventory, not by the user count. A thousand users is one afternoon. Forty SAML apps is a quarter. Everything below was run against Keycloak 26.8.1 in start-dev, and the Okta side is from Okta's published API specification, read on 2026-10-19.

Keycloak 26.8.1 Released: 19 CVEs, One Unrated SAML Bypass

· 8 min read
GR Patil
Phase Two

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.

Keycloak 26.7.5: 14 CVEs, and 26.6/26.4 Have No Patch

· 7 min read
GR Patil
Phase Two

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 LTS: the security backports nobody publishes

· 11 min read
GR Patil
Phase Two

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.

Experimental: ship your Keycloak logs and events to your own OTLP endpoint

· 6 min read
GR Patil
Phase Two

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.