Auth-only constructor to avoid root package dependency closure

[jay-babu]

Summary

Applications that only use Firebase Auth must currently import the root firebase.google.com/go/v4 package to construct an *auth.Client:

app, err := firebase.NewApp(ctx, config, opts...)
client, err := app.Auth(ctx)

Because the root package imports the SDK's other service packages, this pulls Firestore, Storage, Realtime Database, Messaging, Remote Config, App Check, and their transitive Google Cloud dependencies into the Go compile graph.

Would the project accept a non-breaking, auth-only constructor or ID-token verifier in firebase.google.com/go/v4/auth that reuses the existing verifier implementation without importing the root Firebase package?

Use case

Our service only calls VerifyIDToken. It does not use Firestore, Storage, Realtime Database, Messaging, Remote Config, or App Check.

The public auth.NewClient cannot currently be used by an external module because it requires *internal.AuthConfig. Go's internal import rules prevent applications from constructing that configuration, and its documentation directs applications back through firebase.App.

This appears to be the same underlying concern raised in:

• Excessive dependencies for this package #187
• FR: Verify ID tokens without requiring credentials #279

Those issues predate the current module structure and modern cold-build/build-cache costs.

Measurements

We measured a stripped Linux production binary using Firebase Admin Go v4.19.0.

As an upper-bound experiment only, we temporarily replaced root firebase.NewApp(...).Auth(...) initialization with a stub, while retaining the narrower firebase.google.com/go/v4/auth package for the existing token types. The stub was not a functional change and was immediately reverted.

Stripped binary:        124,186,889 B -> 108,671,241 B
Production dependencies:          1,254 -> 1,055

That is approximately 15.5 MB and 199 dependencies behind the root initialization closure in this service. Some of that closure may be eliminated by the linker in other applications, but every imported package still affects compilation and build-cache storage.

Possible API

A narrow client constructor:

client, err := auth.NewClient(ctx, auth.Config{
    ProjectID: projectID,
}, opts...)

Or, if exposing the complete Auth client this way is undesirable, a verifier-specific API:

verifier, err := auth.NewIDTokenVerifier(ctx, projectID, opts...)
token, err := verifier.VerifyIDToken(ctx, idToken)

The new API could reuse the current internal verifier so behavior remains identical, including:

• RS256 signature validation
• Firebase certificate fetching and cache semantics
• project ID audience validation
• https://securetoken.google.com/<projectID> issuer validation
• kid, subject, issued-at, and expiry checks
• clock-skew handling
• *auth.Token output
• Auth Emulator behavior, where applicable

This would be additive and would not change the existing firebase.App API.

If the maintainers agree with the API direction, we would be interested in contributing an implementation and tests upstream.