FusionAuth provides authentication, authorization, and identity APIs. Its web interface and documentation can both contain the product name, so an external title match is not enough to conclude that a host is a production identity server. Discovery and validation need separate steps.
The count-only query title="FusionAuth" used scope all, page 1, and one result on 2026-11-03. It returned 2,426 matches. In the same run, app="FusionAuth" returned 11. The gap between the two methods illustrates why scope and query type belong in the report.
Use the title result as a lead
The title query can surface candidate domains, but a documentation site, a support portal, or an unrelated page can include the name. Confirm the product through an authorized interface, a known deployment record, or a second independent signal. Do not assume that every title match exposes a login or administrative console.
For an owned host, verify the tenant model, application configuration, API keys, signing keys, and administrative roles. Review OAuth and OpenID Connect endpoints, redirect URI validation, token lifetimes, and logging. Those controls matter more than a public page's appearance.
Treat identity discovery as sensitive
An identity server may expose public metadata and login routes by design. That does not authorize password spraying, token testing, or probing for administrative endpoints. If an external asset is suspected to belong to the organization, use the approved asset-owner process and a controlled test environment.
Separate the public discovery question from the configuration question. The first asks whether a product-like host exists. The second asks whether the host's tenant, keys, redirect settings, and recovery flows meet policy. A count cannot answer the second question, and a single successful login page cannot prove that all applications are protected.
Keep a reproducible observation
Record the exact dork, scope, page, time, and count. Compare the title and application results without adding them together. A new run can change because sites are added, removed, or reclassified. A failed request must remain an error in the evidence record.
The action plan is to map candidates to owners, confirm which are FusionAuth instances, and review the production configuration. ZoomEye helps a defender find external identity surfaces that may be missing from the service catalog. The organization still has to establish whether each one is authorized, current, and configured for its risk level.
References
FusionAuth, FusionAuth documentation
FusionAuth, Authentication and authorization concepts
FusionAuth, API documentation
ZoomEye, ZoomEye