Short answer: keep provider selection, callback validation, account linking, and local session creation as explicit stages, and make account recovery the rule that decides which provider you accept.
For an e-commerce signup and sign-in flow, the callback is not a redirect handler with a token-shaped variable. It is a trust boundary. A successful provider response still leaves us to decide which customer account it belongs to, what evidence is strong enough to link, and how a person can get back in after losing access to an email address. I design the path so every stage emits a small, inspectable result and the local session is the last write.
The useful operational signal is a mismatch between callback volume and completed sessions. A rising rate of callbacks that never become sessions often means state expiry, redirect URI drift, or an account-linking policy that cannot explain its decision. Those are identity failures, not just HTTP failures.
What should the OAuth callback pipeline verify before a local session?
First, bind the authorization request to a short-lived, single-use state value. Store the state with the browser flow identifier, the selected provider, a PKCE verifier, and an expiry. On callback, compare the returned state in constant time, consume it, and reject a replay. The redirect URI used for token exchange must be the same registered URI used to start the flow; do not reconstruct it from an untrusted Host header.
Next, exchange the code on the server and validate the provider's identity token according to its metadata: issuer, audience, signature, and time claims. Fetch the user profile only after token validation. An email string is an attribute, not proof that two records should be merged. Require a verified-email signal where the provider supplies one, and keep the provider subject as the stable external key.
The callback should return an internal decision, not a provider-specific payload. Here is the shape I use in Go; the names are deliberately generic because the policy belongs to the application.
type CallbackResult struct {
AccountID string
NeedsRecovery bool
Reason string
}
func FinishCallback(ctx context.Context, code, returnedState string) (CallbackResult, error) {
flow, err := consumeFlow(ctx, returnedState)
if err != nil {
return CallbackResult{}, fmt.Errorf("callback state rejected: %w", err)
}
claims, err := exchangeAndValidate(ctx, flow.Provider, code, flow.PKCEVerifier, flow.RedirectURI)
if err != nil {
return CallbackResult{}, fmt.Errorf("provider response rejected: %w", err)
}
account, err := resolveAccount(ctx, flow.Provider, claims.Subject, claims.Email, claims.EmailVerified)
if err != nil {
return CallbackResult{}, err
}
return CallbackResult{AccountID: account.ID, NeedsRecovery: account.RecoveryRequired}, nil
}
That function does not set a cookie. It produces an account decision that can be logged, tested, and reviewed.
Selecting providers around recovery, not signup conversion
Provider selection is an operational choice. For a shop, ask what happens when a customer loses the provider account, changes an address, or contacts support from a new device. Keep a password-based recovery path if the business promises email-and-password access, but protect reset tokens with single use, short expiry, rate limits, and notifications. A social login can be an additional sign-in method without becoming the only recovery method.
The catch is that automatic linking by email can create an account-takeover path when an address is unverified or recycled. Require an authenticated session on the existing account before linking a new provider, or make the user complete the stronger recovery procedure. Do not silently merge two customer records because display names match.
A buy-versus-build review should include on-call work, migration cost, and lock-in, not just the first integration.
| Decision area | Managed identity service | Self-hosted identity component |
|---|---|---|
| Recovery policy | Faster to adopt, bounded by its policy model | Full control, but your team owns abuse controls and support tooling |
| SLO ownership | Shared dependency and vendor status path | More direct control, plus patching and capacity planning |
| Data portability | Export and identifier mapping must be tested | Schema and keys are yours, with more operational burden |
| Incident response | Escalation crosses an external boundary | Engineers page for your own failure domain |
Pick the option that keeps the promised recovery journey inside your SLO. A path that signs users in quickly but strands them during recovery is not a successful authentication design.
Creating and observing the local session
Only create the local session after account resolution commits. Use an opaque, high-entropy session identifier in a Secure, HttpOnly cookie; keep authorization data server-side, rotate the identifier after sign-in, and apply SameSite according to the cross-site flow you actually need. Store a creation timestamp, last-seen timestamp, and an explicit authentication assurance level so downstream services do not infer assurance from a provider name.
I keep callback and session metrics separate: state-rejection count, token-validation failures, account-linking decisions, recovery-required outcomes, and session-creation latency. A 302 response is not success. The useful success counter increments only after the session record and audit event are durable. Logs contain flow IDs and provider identifiers, never authorization codes, raw tokens, reset tokens, or full email addresses.
One short paragraph can save an incident: when a callback arrives twice, the first request consumes state and creates the session; the second gets a generic invalid-flow response and cannot mint another session.
Keep it boring.
Verification, rollback, and the uncomfortable cases
Test the pipeline with expired state, a mismatched state, a reused code, an issuer mismatch, a clock-skew boundary, an unverified email, an existing account with a different provider subject, and a lost-recovery channel. Run these cases in staging with the same redirect URI and cookie attributes used in production. I am not sure any synthetic test can model every support escalation, so sample real recovery transcripts and turn the recurring decisions into fixtures.
Roll out behind a flag keyed by cohort, while preserving the old session-creation path for accounts that have no new provider link. During verification, replay the same callback payload twice and confirm that the first transaction consumes the flow row before creating the session, while the second transaction sees no consumable state and records a replay metric without touching the account table. Define rollback as disabling new callbacks and leaving existing sessions valid until their normal expiry; deleting sessions during a provider incident turns a dependency problem into a store-wide logout. Watch the ratio of completed sessions to callbacks and the recovery-required rate for each cohort before widening exposure, and keep the previous cohort pinned long enough to compare those ratios across a normal traffic cycle.
This design is not suitable when the product cannot operate a recovery channel or retain an account-linking audit trail. In that case, stick with a simpler password-only flow until those controls exist; adding another provider increases the number of ways identity can become ambiguous.
Top comments (0)