1. Google and GitHub provider applications
  2. AnyOAuth manages provider credentials
  3. Your backend uses project credentials
Provider credentials stay with the service. Your app still authenticates its backend with its own project client ID and secret.

A Google client ID identifies a Google application. A GitHub client ID identifies a GitHub application. Neither is the user, and neither is your application’s session. Before you add more environment variables, separate those jobs.

In a direct integration, you register an application with each provider, configure its callback, store its credentials, and implement its response handling. That’s a reasonable setup when you need to control the provider application. It also makes each new sign-in option a small infrastructure project.

The login button is the visible part. The credential inventory is what you maintain afterward.

Count the integrations, not the buttons

Two buttons can share one application-facing sign-in flow. They don’t have to share provider-specific code in your app.

Consider a small product with Google and GitHub sign-in. A direct integration needs provider application registrations and a backend capable of handling both flows. Your deployment configuration holds the corresponding secrets. When a callback hostname changes, you need to know which registration owns it.

An identity intermediary moves that provider-facing work behind a separate boundary. Your backend integrates with the intermediary; the intermediary integrates with each provider. That changes who operates the provider applications. It doesn’t remove the need to authenticate your backend or validate the browser’s transaction.

ArtifactDirect provider integrationManaged sign-in handoff
Provider application credentialsYour team manages themThe sign-in service manages them
Application-facing callbackYour backend handles each provider’s contractYour backend handles the service’s contract
User sessionYour app or chosen session layerYour app or chosen session layer
Provider API accessPossible with appropriate permissionsDepends on the service; not provided by AnyOAuth

This is an ownership choice, not a magic deletion of OAuth.

Where AnyOAuth fits

AnyOAuth, which we build, manages the provider applications for its configured Google and GitHub sign-in connections. You create a project, register your exact callback URL, and keep that project’s client ID and secret in your backend configuration. You don’t supply separate Google or GitHub developer credentials for this integration.

Your app sends the user through the same authorization, code exchange, and profile retrieval contract for either provider. The sign-in result is a normalized identity, not a Google or GitHub access token.

That’s the boundary worth keeping: your app asks who signed in; it doesn’t inherit permission to read their inbox or repositories. If your feature needs those APIs, you need an appropriate provider authorization integration instead.

  1. Provider secrets: operated by AnyOAuth, never shipped in your application bundle.
  2. Project secret: kept on your confidential backend, used to redeem a handoff code.
  3. Application session: created by your app after it resolves the returned identity.
Moving provider setup does not move your application session or its permissions.

A shorter credential list still needs a backend

The remaining client secret is a real credential. Don’t put it in a browser-prefixed environment variable, a mobile bundle, or a code example committed with an actual value. An environment variable can be private on a server and public in a frontend build; its name alone doesn’t establish the boundary.

For an AI-assisted implementation, ask for two explicit pieces: a browser action that starts sign-in, and a backend handler that validates and redeems the callback. Then inspect the generated changes. Which file reads the secret? Is that file included in the browser bundle? Where is the original transaction saved?

The quickstart explains the transaction contract. If the generated app has only a login button and a token in local storage, it hasn’t implemented the handoff described there.

Choose the tradeoff deliberately

Managing your own provider application gives you direct control over its branding, configuration, and API permissions. With shared provider applications, users see the service’s provider identity on the consent screen. That matters if your product requires a particular consent-screen brand or a provider-specific approval path.

A managed sign-in handoff suits an app that needs familiar social accounts and a profile, while retaining its own sessions. A direct provider integration or another auth platform may fit better when you need provider APIs, a broader identity stack, or control of every registration.

Start by writing down those requirements. Then use the smallest integration that actually satisfies them. Our next field note explains one project secret across multiple sign-in providers, including what changes when you add a second app.

Sources and implementation references