40,059 Keycloak Servers: Where the Identity Provider Is the Asset

#keycloak #exposure #identity

40,059 Keycloak Servers: Where the Identity Provider Is the Asset

An identity provider is the component that decides who a user is for every application connected to it. When that component is reachable from an untrusted network, the exposure is not about data leakage alone. It is about the trust anchor for authentication across an estate.

What the server presents

Keycloak provides authentication, single sign-on, and identity brokering. Its documentation describes the administrative console, the account console, and the realm model that separates tenants. The administrative console is the surface with the greatest authority: an authenticated administrator can configure clients, identity providers and user federation.
The relevant exposure property is that the login, account and administrative paths are served from the same interface, and that the administrative console is reachable wherever the server is reachable.

The measurement

One query was run against the international dataset on 2026-09-27 with the default all asset scope:

app="Keycloak"

Observed result: 40,059 matching services.
A single verified figure is a deliberate choice here. Adding an unverified port query would produce a larger number with less meaning, and the fingerprint is strong enough for this product that one figure describes the population adequately.
The count describes services presenting a Keycloak fingerprint. It does not describe whether the administrative console is exposed separately, whether default administrative credentials were changed, or whether the realm configuration permits self-registration.

The exposures worth checking first

Three configuration outcomes account for most of the risk in an exposed identity provider.
A reachable administrative console with a default or weak administrative credential. The console is the path to every configured client secret.
A realm configuration that permits self-registration or that grants broad default roles to new users, which turns the provider into a way of obtaining an account in connected applications.
A production deployment still configured with the development defaults, including relaxed hostname checking and a permitted insecure connection, which affects how tokens are issued and validated.
None of these is visible to a fingerprint count, and all three are visible to a fifteen-minute configuration review.

Operational checks for an identity provider estate

Confirm the administrative console is not reachable from an untrusted network, ideally by binding it to a separate address or by fronting it with an access proxy.
Confirm that administrative credentials are unique per environment and stored in a managed secret store.
Confirm the realm's registration, default role and token lifetime settings against the intended behaviour.
Confirm that the client configuration does not permit a wildcard redirect, which is the configuration that makes an authorisation code interception possible.
Confirm that the provider appears in external attack surface monitoring, because a new identity endpoint that the inventory does not know about is a trust anchor nobody is watching. Point four is the check most frequently omitted, and it is the one that affects every application connected to the provider.

Placing the number in context

40,059 services presenting this fingerprint is a population that is large enough to describe a common deployment pattern and specific enough to be reviewable. Both the product fingerprint and the surrounding queries are available from https://www.zoomeye.ai/, and the useful application is against the organisation's own ranges, where the result can be compared with the identity inventory.
ZoomEye's product search gives the confidence that recording a single figure requires: the field is identified, the query is published, and the number can be reproduced.