DEV Community

kozhevniko
kozhevniko

Posted on

FusionAuth: 2,411 title matches on the authentication server that issues your tokens

FusionAuth: 2,411 title matches on the authentication server that issues your tokens

An authentication server signs the tokens that applications accept as proof of identity. FusionAuth fills that role for many deployments, and a ZoomEye title search for title="FusionAuth" on 2026-10-01 returned 2,411 matches.

What the query measured

The figure is a title-field result. It counts pages that render the FusionAuth name in their HTML title, which includes the administrative interface, the login pages served for tenant applications, and documentation instances. It does not confirm a version or an installation, and it should be read as a population indicator.
Two thousand four hundred and eleven matches give an owner a list of manageable size. Reconciling it against a host inventory is a task of hours rather than weeks, which makes the query a practical inventory input rather than a research exercise.

The material the server holds

FusionAuth stores user records, application registrations, signing keys and the configuration for the identity providers it federates with. Its documentation covers tenants, applications, API keys, and the way signing keys are generated and rotated.
Key material is the important part. A signing key that is reachable by an unauthorised party allows tokens to be forged for any application that trusts the server, and the tokens are accepted without further checks by design. The same applies to the API keys that administrative clients use.

The checks that follow from 2,411

The review is familiar to anyone who has audited an identity server. Is the administrative interface reachable from outside the perimeter, and does it require multi-factor authentication? Are the API keys scoped, rotated and stored outside the application configuration? Is the login page for each tenant exposed only where it needs to be?
Reviewing the list also involves a question that the count cannot answer: whether any of the matches belong to the organisation without being in its inventory. Measurement finds services that documentation misses, and identity servers are the ones where that gap matters most.

Implications

Identity servers are configured once and then depended upon for everything else. The count sets the population, and the configuration review decides whether the dependency is a controlled one.

References

Top comments (0)