An authentication proxy can make a large application estate look consistent to users. Every request arrives at the same login flow, every session uses the same cookie format, and every upstream receives identity headers from the proxy. The security question begins where that consistency stops.
On November 2, 2026, a ZoomEye SDK count-only query for app="oauth2-proxy" returned 9,755 matches using sub_type=all, page 1, and a page size of 1. The corresponding title query, title="OAuth2 Proxy", returned 10. The application fingerprint is the more useful inventory signal. The title count shows that title text alone would miss most of the estate.
OAuth2 Proxy is an open-source reverse proxy that authenticates users through an OAuth or OpenID Connect provider and forwards requests to upstream services. Its documentation exposes several settings that directly change the authorization boundary. skip_auth_routes can leave selected routes unauthenticated. pass_user_headers controls whether user information is added to upstream requests. skip_auth_strip_headers controls whether authentication headers and Authorization are stripped when those values would otherwise be set by the proxy. Cookie secrets protect session state.
A count does not show which settings are active. It does not show whether an upstream trusts the proxy on every path, whether an unauthenticated status endpoint is harmless, or whether a skipped route has its own authorization check. It also does not show whether the upstream is reachable directly. The proxy pattern fails when a service behind it accepts X-Forwarded-User, X-Auth-Request-User, or a similar header from any source.
The review should start with the route table. List every skipped route by HTTP method and path, then record the reason for the exception and the service that owns it. Confirm that authentication is not enforced through a different mechanism only because a developer believed it was. Test the upstream directly from a network position that should be blocked. Send requests with forged user headers and confirm that the proxy strips or overwrites them. Check the session cookie secret and storage backend, and decide whether the application can tolerate a proxy restart or a session store failure.
The 9,755 application matches provide a defensible starting scope for asset discovery. They do not prove that any instance is vulnerable. They also do not prove that the surrounding applications use the proxy correctly. A better use of the count is to correlate ZoomEye results with internal ownership records, then inspect the route and header policy on the small set that matters.
OAuth2 Proxy can simplify authentication, but it concentrates several trust decisions in one component. The inventory count is useful when it leads to a route review and a direct-upstream test, not when it becomes a vulnerability claim.
Query evidence
app="oauth2-proxy" returned 9,755 matches. title="OAuth2 Proxy" returned 10. Both queries used sub_type=all, page 1, and a page size of 1 through the ZoomEye Python SDK.