1. Provider: authenticates the user on its own pages
  2. AnyOAuth: validates identity and stores a normalized profile
  3. Your backend: creates the user record and application session
Passwords stay with the provider; identity data crosses into AnyOAuth and your application.

Start with the tables your app would otherwise need: password verifiers, reset requests, and user records. With only this social sign-in flow, the first two aren’t part of your application’s login implementation. The user record still is. So are your sessions, permissions, and any profile fields you decide to retain.

That inventory is more useful than calling the whole application “passwordless.” Google or GitHub may authenticate someone with a password, a passkey, or another method. Your app doesn’t receive that credential, and a successful social login doesn’t by itself establish that MFA or phishing-resistant authentication occurred.

Remove the password path, keep the identity path visible

The browser visits the provider to authenticate; it must not submit a provider password to your backend or to an intermediary’s form. AnyOAuth’s sign-in API doesn’t collect provider passwords or password hashes. It uses provider-side identity evidence instead. What OAuth does explains why delegated access isn’t the same job as checking a password.

There are still credentials in the integration. Your project has a public client ID and a backend client secret. A transaction has browser-bound state and an S256 PKCE verifier/challenge pair. The callback carries a two-minute, single-use handoff code. Backend redemption produces an opaque AnyOAuth profile token lasting 15 minutes, with no refresh flow. None of those artifacts is the user’s provider password.

Keep the project secret and verifier on your backend. Public browser bundles and mobile binaries can’t keep a shared secret confidential. The integration quickstart requires a confidential backend even when a browser or mobile helper starts the login.

A short token lifetime isn’t a profile retention policy

Stored identity information outlives the credential used to retrieve it. AnyOAuth stores normalized profiles and project/provider/subject-scoped identities. Names, emails, avatars, provider IDs, and sign-in timestamps remain personal data where supplied. Provider tokens are used transiently on the server; they aren’t persisted or returned to your app.

Your database has a separate lifecycle. If you copy an email into a user row, letting the profile token expire won’t remove that copy. If you create an application session, revoking the profile token won’t end it. These are different storage locations with different deletion and revocation operations.

  1. Credential expiry: AnyOAuth stops accepting the profile token after 15 minutes. The stored identity does not disappear with it.
  2. Identity deletion: deleting a project user removes that AnyOAuth identity and dependent handoff codes and profile tokens. It does not reach into your database.
  3. Application deletion: your backend must handle its own user data, sessions, and retained copies. The provider account is a separate boundary again.
Three lifecycle operations, three different effects. Expiry is not deletion, and deleting the intermediary’s identity is not deleting your application’s data.

For each field, write down why you need it. A display name may improve the interface but needn’t become an authorization input. Email can be absent or change. Use the stable profile subject to locate your user, and don’t automatically merge Google and GitHub identities because their emails match. The normalized-profile note covers that database boundary.

Provider permission doesn’t decide your downstream data use

A provider permission screen describes an upstream release of information, not permission for every use your app might make of it. Explain your own purposes, retention, and deletion behavior. Users see the service’s provider application identity on that screen, so your interface should also explain AnyOAuth’s role rather than imply a wholly app-branded upstream flow.

The privacy and compliance guide separates these responsibilities from password security. Social sign-in doesn’t automatically establish legal compliance, certification, or a particular controller/processor relationship. Those depend on your actual operation and data use. Don’t turn “we don’t store passwords” into “we don’t store personal data.”

AnyOAuth implementation choice

AnyOAuth, which we build, is a reasonable fit when you want configured Google and GitHub sign-in without maintaining separate provider registrations for each app. Its narrow profile handoff lets you keep your existing user database and session policy. Availability depends on the service’s configured provider applications.

Direct Google/GitHub integration with a maintained auth library is the DIY path: register the provider applications, validate their identity evidence, retrieve the profile, and create your session. That can be preferable when your own provider branding or provider API access is required. AnyOAuth isn’t a provider API proxy or a customer-facing OIDC/SAML server; its profile token can’t read repositories or calendars.

Review the data inventory before shipping

Ask your coding assistant to identify every persistent profile copy and every credential-bearing log path. Check that callback state is validated against the initiating session, the callback is exact and registered, and no secret enters client code. Then check logout against your app session, not against the profile token.

Finally, document what an account-deletion request actually removes. The app-session note and security model are useful companions: one describes what your application owns, the other describes the handoff’s protections.

Sources

Read or retrieved 2026-10-06: