1. Requirements: identity-only login or ongoing provider API access?
  2. Integration: confidential backend, project credentials, exact callback
  3. Application: user policy, owned sessions, permissions, and data use
Decide the required boundary first; the button and callback implementation follow from it.

Write a short acceptance contract before asking an assistant to add a login button. Include the supported providers, callback owner, stable identity key, session owner, and what happens when someone chooses a different provider. Those answers prevent the generated implementation from quietly choosing account policy for you.

For example, an app that only needs to identify someone has a different requirement from an app that continuously reads their calendar. Both may begin with a familiar account, but they need different credentials afterward. The homepage questions are useful starting points because they expose that distinction before it becomes a database migration.

Is the job sign-in, provider access, or enterprise federation?

Identity-only login is the current AnyOAuth scope. Configured Google and GitHub sign-in produce a normalized profile through a backend exchange. There are no arbitrary scopes, provider API proxy, or provider-token vault. If your next feature requires repository or inbox access, plan a separate provider integration; don’t infer that capability from the sign-in button.

Enterprise federation is another requirement again. AnyOAuth isn’t a customer-facing OIDC or SAML server. OAuth versus SAML explains why social login and an enterprise’s federation requirement aren’t interchangeable. What OAuth is separates delegated authorization from the application login you eventually create.

Who holds the credentials and receives the callback?

A confidential backend must redeem the code. Browser and mobile helpers can start the login, but they don’t make a bundled project secret private. Your project has a public client ID and a backend secret; independent applications can have separate projects with their own callbacks and identities. One AnyOAuth account isn’t one account-wide secret for every app.

Register the exact backend callback, require browser-bound state and S256 PKCE, and keep the original verifier in the saved server-side transaction. The two-minute handoff code is single-use. The exchange must include the secret, original verifier, and saved callback. If there’s no backend to own that work yet, that’s an architecture task before it’s a UI task.

The one-secret explanation covers the project boundary. Use the authorization-code reference when reviewing which redirect carries which code.

What makes someone the same application user?

Your stable key should be the normalized subject, not email. AnyOAuth identities are scoped to project, provider, and provider subject. Names, usernames, email, email verification status, and avatars are profile information; unavailable fields are nullable. A schema requiring every display field will reject otherwise valid identities.

Matching emails do not automatically merge Google and GitHub accounts. AnyOAuth currently has no account-linking feature. Decide how to explain separate identities and what recovery your app can honestly offer. If you need linking, it deserves a proof-of-control design; “upsert by email” isn’t that design.

  1. Known subject: the backend locates the existing user and applies the app’s login policy. Display-field changes do not choose a new identity.
  2. New subject: the backend follows the app’s registration policy, even when an email matches an existing row. No silent merge occurs.
  3. Missing contact field: the app either continues without it or requests the information through its own explicit process. A missing email does not justify inventing one.
Three user-resolution branches to specify before implementation. Identity continuity and contact-data completeness are different requirements.

How long should the app keep someone signed in?

Your app sets its session policy. AnyOAuth’s opaque profile token lasts 15 minutes and has no refresh flow. Retrieve the profile, find or create the user, issue your own secure session cookie, and revoke the profile token when finished. Neither that expiry nor revocation determines how long your app session lasts.

Define logout, idle expiry, permission checks, and disabled-user behavior in the application. A profile response isn’t a role assignment. The session ownership note is the useful companion here, rather than a plan to refresh the profile credential as if it were a session cookie.

What will people see, and what data will you keep?

Users see the service’s provider application identity on the consent screen. Check that this matches your intended experience. If you need your own provider consent identity, direct provider registration may be the better choice. Also verify Google/GitHub availability from the actual service configuration before presenting a button.

List every profile field retained in your database and why it’s needed. Removing local password handling doesn’t remove personal-data responsibilities or establish automatic legal compliance. Deletion in AnyOAuth doesn’t delete your application’s copies or upstream provider accounts. Treat those lifecycle boundaries as product behavior, not footer copy.

AnyOAuth implementation choice

AnyOAuth, which we build, is a fit when you need the configured Google/GitHub identity-only contract and want to keep your own user/session system. The quickstart specifies the required callback and backend flow; secure handoffs supplies failure-oriented review checks.

The DIY route is your own provider registrations and maintained Google/GitHub libraries, with identity validation and profile normalization feeding your database. Prefer that for your own upstream branding or provider API scopes. If you require a broader managed account/session system or enterprise federation, evaluate an auth platform such as Auth0 or WorkOS against that requirement instead of stretching a profile-only handoff.

Your final contract should say what succeeds and what stops: denied login, wrong state, wrong verifier, replayed code, missing fields, and unsafe return URLs. The PKCE reference gives the verifier reasoning. A human should be able to read these outcomes without decoding the generated implementation first.

Sources

Read or retrieved 2026-10-06: