1. One application project
  2. One client ID and backend secret
  3. Google or GitHub sign-in
Provider choice changes the sign-in route, not the project's backend credential. Independent projects have independent credentials.

“One secret” needs a noun after it. One secret for a project is a useful operational boundary. One secret copied into every app you ship is a different decision, with different consequences.

Suppose you’re building a scheduling app and a separate developer tool. Both need Google and GitHub sign-in. You can reuse your integration approach without making their identities, callbacks, and backend credentials one shared bucket.

The goal is to reuse the code you understand, not to erase the boundary between products.

Provider choice isn’t project choice

A project represents your application-facing integration. A provider is the account the user chooses to sign in with. Those are separate dimensions.

Within one project, the same backend credential supports each available provider. The authorization request chooses Google or GitHub. Your backend still validates the returned state, redeems the code, fetches the profile, and issues its own session.

That means your sign-in handler doesn’t need a branch that selects a Google client secret or a GitHub client secret. It needs the credentials for the project that initiated the transaction. Provider-specific work belongs behind the sign-in service’s boundary.

It also means you shouldn’t interpret “one integration” as “one user identity across every provider.” A person’s Google identity and GitHub identity remain different until your application deliberately establishes a link. Matching email addresses don’t establish that link.

A second app gets its own boundary

Separate projects give independent apps separate credentials and project-scoped subjects. The same provider account signing into two projects is not a promise of one global application user ID.

QuestionWithin one projectBetween independent projects
Backend credentialSame project client ID and secretEach project’s own credentials
Callback configurationProject’s exact registered callbacksConfigured separately
Stable identityStable within the project/provider accountProject-scoped, not global
Session cookieDefined by your applicationDefined by each application

Multiple registered callbacks can serve one application’s deployment needs, but registration doesn’t make unrelated frontends a shared sign-on system. If you want shared sessions across products, design that explicitly. AnyOAuth’s profile API is not a cross-app session service.

  1. Scheduling app: project A, its callback, its backend secret, its users.
  2. Developer tool: project B, its callback, its backend secret, its users.
  3. Reusable integration code: the same transaction and profile-handling pattern, configured for the correct project.
Reuse the implementation pattern while keeping application credentials and identities separate.

Where AnyOAuth fits

AnyOAuth, which we build, gives each project a client ID and backend secret for its available sign-in providers. The current integration supports configured Google and GitHub connections. Create separate projects when your independent apps should have independent credential and identity boundaries.

Keep the project configuration in a server-side module. Route a transaction back to the same project’s backend configuration that created it. Don’t let a visitor supply an arbitrary client ID, secret, or redemption endpoint through callback parameters.

The quickstart gives you a reusable transaction contract. You don’t need a different provider credential set for each button.

Rotating a project’s secret retires its pending transactions, codes, and profile tokens. Your application should be able to handle a sign-in retry during that transition. Don’t treat a credential change as a transparent event for in-flight login attempts.

Your application-owned sessions have a separate lifecycle. Rotating a project secret is not a substitute for revoking your app’s cookies after an incident. The distinction is the same one we cover in your app owns the session: sign-in credentials establish the handoff; the app’s session keeps the user signed in afterward.

For a generated integration, write the expected boundaries in the prompt: one server credential per project, no client secrets in frontend code, transaction configuration preserved through the callback, and no global user table keyed only by email. Then review whether the code actually follows them.

That is the useful version of “one setup”: fewer provider-specific moving parts, with application ownership still visible.

Sources and implementation references