1. Sign-in returns a verified identity
  2. Your backend resolves an application user
  3. Your application creates its own session
Provider identity establishes who signed in. The application owns the user mapping, session lifetime, and authorization checks.

The callback has returned successfully. Your backend has fetched a profile. The browser follows a redirect to /dashboard.

What makes the next request authenticated?

If the answer is “the login request worked,” there’s a missing step. Requests need a session or another application authentication mechanism the backend can validate. A profile retrieved during one transaction does not automatically authenticate future requests.

Resolve the identity before issuing the session

Your application should map the stable sign-in subject to its internal user record. That record becomes the basis for sessions and permissions.

The mapping is often a separate identity table: external subject points to internal user ID. It lets your application evolve its user model without turning a provider’s mutable display data into its primary key. It also gives you somewhere to enforce uniqueness deliberately.

Don’t find an existing user by matching email and quietly attach the new identity. A normalized profile isn’t an account-linking protocol. The lookup should preserve the identity boundary unless you have an explicit linking flow.

Then create a session through your existing framework or session implementation. Regenerate the session identifier at authentication rather than carrying an anonymous session ID into an authenticated context unchanged.

A session is your application’s credential

An application session authenticates later requests to your application. It doesn’t need to be the token used to fetch the sign-in profile.

For a conventional browser app, a server-managed session with an opaque cookie is a familiar choice. Set cookie protections appropriate to the deployment, including HttpOnly, Secure in HTTPS production, and a deliberate SameSite policy. Define expiration and server-side revocation, not just a browser cookie’s expiry.

HttpOnly prevents script access to the cookie value; it doesn’t by itself prevent CSRF or all consequences of XSS. Protect state-changing requests with the measures your framework and architecture require. The login flow’s state parameter is not a general CSRF defense for the rest of your application.

If you already use a framework’s session layer, integrate with it rather than adding a second, unrelated “OAuth session” storage mechanism.

  1. Identity lookup: stable subject maps to internal user ID.
  2. Session validation: each application request resolves the active session to that user.
  3. Permission check: the requested operation is allowed by the application's trusted records.
Being signed in and being allowed to perform an operation are separate checks.

Logout and deletion have separate consequences

Logging out of your app should end its session. Revoking an AnyOAuth profile token ends that token’s access to the profile API. Deleting an identity in AnyOAuth revokes associated service credentials. None of those statements promises that an unrelated application cookie disappears automatically.

Write down the behavior your app needs for user deletion, account suspension, passwordless reauthentication, and access changes. A long-lived session should not keep an old permission forever merely because its initial login was valid.

Likewise, removing a user’s access to a team may require no change to their social identity at all. Your application can deny a team operation while the user remains signed in to their personal account.

Where AnyOAuth fits

AnyOAuth, which we build, supplies the identity handoff and normalized profile. You retain the application user record, session, and permission model. Its opaque profile token expires after 15 minutes and isn’t a replacement for your application’s session cookie.

That division fits an app with an existing backend and session layer. If you want a platform to provide a broader managed user/session stack, evaluate one on those requirements. Don’t select a profile handoff assuming it includes every piece of an identity platform.

The quickstart ends with finding or creating a user and issuing your session. That comment represents real application work, not a line to skip.

Give the coding assistant an acceptance contract

Ask it to explain how an anonymous browser becomes an authenticated application session, then trace the actual files. You should be able to locate the identity lookup, the session creation, the cookie settings, the logout operation, and a protected route’s permission check.

Try reviewing the failure paths before polishing the sign-in screen: cancelled login creates no session; missing transaction rejects the callback; a missing profile field doesn’t merge accounts; a revoked application session can’t load the protected page.

Those checks tell you more than whether a green login button redirected correctly. To inspect the preceding handoff, continue with secure OAuth handoffs.

Sources and implementation references