Keycloak reCAPTCHA Alternative for European Teams (2026)

Keycloak ships with reCAPTCHA built into its registration flow. For European organisations, that default creates cookies, US data transfers, and a privacy documentation burden on the three flows that matter most: login, registration and password reset. This guide explains how to replace reCAPTCHA in Keycloak with a cookieless, EU-hosted alternative and walks through the exact configuration for each authentication flow.

Estimated reading time: 14 minutes

---

At a Glance

---

---

Why reCAPTCHA creates specific problems in Keycloak

Most reCAPTCHA discussions focus on contact forms. Keycloak is a different situation entirely. It is an identity and access management system: the layer that controls who can log in, create an account, or recover a password across your applications. That means reCAPTCHA here sits on authentication flows, not marketing pages.

For European organisations running Keycloak in production, this creates three issues that are more serious than on a typical website form.

Enterprise and public-sector Keycloak deployments attract the strictest reviews. DPOs, procurement committees, and security architects ask harder questions about third-party scripts on authentication pages than on any other part of a website. A CAPTCHA that introduces no cookies, no US data routing, and a much simpler third-party review profile is structurally easier to defend, and faster to approve.

The _grecaptcha cookie runs on authentication pages. Google confirmed this cookie persists after the April 2026 processor model change. On a login page that employees or customers must complete before they can access any service, they cannot meaningfully opt out of a cookie that protects the very flow they need to use. This is harder to resolve than the same cookie on a contact form.

Verification routes through Google infrastructure. For organisations in regulated sectors such as healthcare, finance, or the public sector, processing personal data via US infrastructure requires active transfer documentation under GDPR. On an authentication system that handles credentials, this adds governance overhead that security and compliance teams would rather avoid entirely.

---

Keycloak CAPTCHA alternatives compared

Several CAPTCHA providers offer Keycloak plugins, but the market is much more constrained here than for WordPress or TYPO3. Most community extensions break on Keycloak major version upgrades and receive limited maintenance. The Keycloak CAPTCHA ecosystem is much smaller than the WordPress or TYPO3 ecosystem. In practice, most teams evaluating a modern Keycloak CAPTCHA layer look at CAPTCHA.eu, Friendly Captcha, legacy reCAPTCHA, and a small number of community-maintained options such as ALTCHA or hCaptcha integrations.

SOLUTION	COOKIES	DATA LOCATION	FLOWS COVERED	PLUGIN TYPE	VERSION REQUIREMENT
CAPTCHA.eu	No	Austria (EU)	Login, Registration, Password Reset	Official JAR	Keycloak 22.0.3+
Friendly Captcha	No	Dedicated EU-only endpoint from Advanced plan. Lower tiers may use global infrastructure.	Login, Registration, Password Reset	Official plugin	Keycloak 26.1.0+ and Java 17+ required
hCaptcha	Yes	US-based	Registration only	Community JAR	Limited maintenance
ALTCHA	No	Your own infrastructure	Registration only	Community JAR	Self-hosted backend required
reCAPTCHA v2	Yes (_grecaptcha)	US-based	Registration (built-in only)	Built-in	Login and Reset require custom extensions

---

The three flows to protect

Keycloak organises authentication as configurable flows, which are independent sequences that you modify separately in the Admin Console. Understanding what each flow does helps you decide which ones to protect first and why.

The browser (login) flow is the standard login page that users see when they access a Keycloak-protected application. It carries the highest traffic volume and is the primary target for credential stuffing and brute-force attacks: automated attempts to access accounts using stolen or guessed credentials at scale.

The registration flow covers account creation. Without CAPTCHA protection here, bots create fake accounts in bulk, which degrades service quality, skews user analytics, and enables abuse of trial periods, referral programs, or free tiers.

The reset credentials flow handles password recovery. Attackers target it to trigger recovery emails at scale, overload mail infrastructure, enumerate which usernames exist in the system, or probe for account takeover opportunities. It is the least-discussed of the three and often the last one teams think to protect. Leaving it open while protecting the other two creates a gap.

One important limitation to know upfront: Keycloak’s built-in reCAPTCHA only protects the registration flow natively. To protect login and password reset with reCAPTCHA, you need custom extensions. CAPTCHA.eu covers all three with the same JAR and follows the same configuration pattern for each, which is one reason teams find the migration straightforward.

---

Which Keycloak version are you running?

Before you install anything, check your Keycloak version. It affects which alternatives are available to you.

If you run Keycloak 26.1.0 or later with Java 17 or later, both CAPTCHA.eu and Friendly Captcha are available. Both offer officially maintained plugins covering all three flows. CAPTCHA.eu also supports Keycloak 22.0.3 and later, which makes it a fit for teams running older installations.

If you run an older Keycloak version (Keycloak 24.x, 25.x, or anything below 26.1.0), Friendly Captcha’s Keycloak plugin is not compatible. Their plugin explicitly requires Keycloak 26.1.0+ and Java 17+. CAPTCHA.eu supports a broader version range.

If you run Red Hat Build of Keycloak (RHBK) or the older Red Hat SSO product, the version mapping differs from upstream Keycloak. RHBK 24 corresponds roughly to upstream Keycloak 24. Verify against the plugin’s documented compatibility before rolling out to production.

---

Installation: adding the CAPTCHA.eu plugin to Keycloak

The installation is a one-time step that applies to all three flows. Once the JAR is in place, you configure each flow separately in the Admin Console.

---

Configure the browser login flow

<#if captchaEnabled ??>
  <script>
    var CaptchaDOMReady = function (callback) {
      document.readyState === "interactive" || document.readyState === "complete"
        ? callback()
        : document.addEventListener("DOMContentLoaded", callback);
    };
    CaptchaDOMReady(function() {
      KROT.setup("${captchaEUPublicKey}");
      var f = document.getElementById("kc-form-login");
      KROT.interceptForm(f);
    });
  </script>
</#if>

If you prefer not to edit your theme manually, use the pre-built theme included in the CAPTCHA.eu extension source at /theme/captcha.

---

Configure the registration flow

<#if captchaEnabled ??>
  <script>
    var CaptchaDOMReady = function (callback) {
      document.readyState === "interactive" || document.readyState === "complete"
        ? callback()
        : document.addEventListener("DOMContentLoaded", callback);
    };
    CaptchaDOMReady(function() {
      KROT.setup("${captchaEUPublicKey}");
      var f = document.getElementById("kc-register-form");
      KROT.interceptForm(f);
    });
  </script>
</#if>

---

Configure the password reset flow

<#if captchaEnabled ??>
  <script>
    var CaptchaDOMReady = function (callback) {
      document.readyState === "interactive" || document.readyState === "complete"
        ? callback()
        : document.addEventListener("DOMContentLoaded", callback);
    };
    CaptchaDOMReady(function() {
      KROT.setup("${captchaEUPublicKey}");
      var f = document.getElementById("kc-reset-password-form");
      KROT.interceptForm(f);
    });
  </script>
</#if>

---

Deployment notes: Docker, Kubernetes, and Red Hat SSO

How you install the JAR depends on how you run Keycloak. The Admin Console configuration steps are identical in all cases. Only the file placement differs.

Standard installation (bare-metal or VM): Copy keycloak-captcha.jar directly into the providers/ directory of your Keycloak installation and restart. Keycloak picks up the new provider automatically on startup.

Docker: Add the JAR at build time using a COPY instruction in your Dockerfile, or mount it at runtime via a volume. The providers directory inside the container is typically at /opt/keycloak/providers/. A minimal Dockerfile approach looks like this:

FROM quay.io/keycloak/keycloak:latest
COPY keycloak-captcha.jar /opt/keycloak/providers/
RUN /opt/keycloak/bin/kc.sh build

Kubernetes: Mount the JAR using an initContainer that copies it into a shared volume, or use a ConfigMap if your cluster supports binary data. The most reliable production approach is building a custom Keycloak image with the JAR baked in, then referencing it in your Deployment manifest. This avoids volume mounting complexity and keeps your deployment reproducible.

Red Hat Build of Keycloak (RHBK) and Red Hat SSO: RHBK follows the same providers directory approach as upstream Keycloak, but the version numbers differ. RHBK 24 corresponds roughly to upstream Keycloak 24. If you run Red Hat SSO 7.x, the older product based on a different Keycloak version, verify plugin compatibility carefully before deploying to production. The CAPTCHA.eu plugin page documents current compatibility; when in doubt, test on a staging realm first.

---

How to verify the migration worked

Once all three flows are configured, a quick verification pass confirms everything is working before you treat the migration as complete.

In the CAPTCHA.eu Dashboard, open your domain and check the verification log. After submitting each protected flow (login, registration, password reset), you should see corresponding verification events appear in the log within seconds. If a flow is missing from the log, the CAPTCHA.eu step is not active for that flow. Return to the Admin Console and check that the flow is correctly bound.

On the frontend, submit a test entry for each flow on both desktop and mobile. The verification should complete silently in the background with no visible challenge. If you see an error or the form refuses to submit, check that the Public Key in the plugin settings matches the one in your CAPTCHA.eu Dashboard, and that your FTL snippet references the correct form element ID for each flow.

For Kubernetes deployments, also verify that the JAR is correctly loaded after a pod restart by checking Keycloak startup logs for the provider registration confirmation. If the provider does not appear in the logs, the JAR is not being picked up. Recheck the volume mount or image build.

---

GDPR checklist after switching

The technical migration covers the CAPTCHA layer. These steps complete the compliance picture.

Update your privacy notice. Remove the reCAPTCHA entry and replace it with a short CAPTCHA.eu entry that names Austria as the processing location and bot protection on authentication flows as the purpose.

Review your consent management setup. If your Keycloak deployment included any cookie disclosure for reCAPTCHA, remove or revise that entry. For CAPTCHA.eu, no cookie-based consent mechanism is needed for the CAPTCHA layer itself. Session cookies and OIDC tokens are separate and unaffected.

Update your processing records. Replace Google as the CAPTCHA-related processor in your Article 30 records. A standard DPA is available from CAPTCHA.eu for this purpose.

Confirm with your security and DPO teams. For enterprise and regulated-sector deployments, confirm the authentication flow changes with your security architect and DPO before go-live. This is standard practice for any authentication system change.

---

Frequently Asked Questions

---

Related reading

---