76,015 Keycloak Titles and 40,080 Keycloak Fingerprints Describe Different Assets
When two queries for the same product disagree by nearly a factor of two, one of them is not measuring what you think. For Keycloak the split is unusually wide, and the reason is instructive: the two dimensions catch different deployment patterns rather than producing a measurement error.
Context and method
Counts come from the ZoomEye index on 23 October 2026, each query with sub_type=all, pagesize=1, page 1. Totals count fingerprint matches, not installations, and carry no information about authentication configuration.
| Query | Total |
|---|---|
app="Keycloak" |
40,080 |
title="Keycloak" |
76,015 |
The title query reports 35,935 more matches than the application fingerprint. That is the opposite direction from most products this index covers, and it needs explaining before either number gets quoted.
Why a title can outrun a fingerprint
An application fingerprint has to be specific: a header, a path, a response body fragment the index can attribute to this product and no other. A title match only requires the word to appear in the HTML title element.
The title dimension therefore catches a broader set of pages. A Keycloak login page reached through a reverse proxy that rewrites headers still carries the product name in its title. An administrative console, a documentation landing page rendered from the same theme, or a custom login template inheriting the default title all match title while failing the stricter app rule.
The two numbers are not competing estimates of one quantity. They are overlapping populations: 40,080 pages the index can positively attribute to Keycloak, and 76,015 pages that mention it in the title, a superset including instances the fingerprint rule misses and pages that merely use the name.
What an identity provider on the internet means
Keycloak is an authorization server. Its purpose is issuing tokens other systems accept. An instance reachable from the internet is not simply a login page; it is the component that decides who is who for everything behind it.
The security-relevant consequences come from that role rather than from any specific bug.
- The login page is the one page in the estate that must be reachable by unauthenticated users. It is also where credential stuffing lands.
- The admin console is a separate concern. Where it shares a hostname with the login flow, exposure in one is exposure in the other.
- Client registrations, realm settings and identity provider federation configuration are the crown jewels. They define which applications trust the instance and what claims it will vouch for.
- An authorization server that goes offline is an outage for every application behind it, which is why these rarely come down for maintenance and often run whatever version was installed the day they went live.
Turning the split into an inventory question
The useful move is not picking one number. It is checking both dimensions inside your own address space and explaining any divergence.
If your organisation appears in title but not app, either the fingerprint rule cannot see your deployment because a proxy rewrote what it needs, or the page matching the title is not a real instance. Both are worth knowing. The first means your asset register is more complete than the public index. The second means the index is showing you something you do not recognise, which is worse.
If your organisation appears in app but not title, something is replacing the visible product name. Sometimes that is deliberate hardening. Sometimes it is a template nobody reviewed.
Limits of this measurement
Nothing here establishes whether any given instance permits self-registration, exposes the admin console, or runs a version with a known flaw. Those require authenticated inspection. What the index establishes is the size and shape of the internet-facing population, which is enough to decide whether an inventory conversation is overdue.
References
- ZoomEye search: https://www.zoomeye.org/
- Keycloak documentation, securing the admin console: https://www.keycloak.org/documentation
Top comments (0)