OAuth Signup Needs More Than Email Proof

OAuth makes signup feel simple: a user chooses a provider, grants access, and arrives in the application with an email address attached. The dangerous shortcut is treating that email address as complete proof of identity.

An email claim can be useful. It is not automatically a durable identity signal, a recovery authorization, or permission to skip every local account control. A safer design starts by separating those decisions.

The assumption to challenge

Many applications implement a flow close to this:

1. Receive an OAuth callback.
2. Read the provider's email claim.
3. Find a local account with that email.
4. If none exists, create one and mark it verified.

The flow may be correct for a narrow product, but step four often hides the real policy. Which provider asserted the address? Was the address verified by that provider? Can the claim change later? Does the user already have a password account? Is the application using the same email for notifications and account recovery?

Those are seperate questions, and collapsing them into one boolean called email_verified makes review harder.

A small threat model

Consider three assets: the local account, its recovery path, and the user's private data. Now list plausible failures:

• A callback is replayed after the original OAuth session has expired.
• An application trusts an unverified email claim from a provider.
• Two local accounts are merged because their normalized addresses match.
• A user loses access to the provider account, but the local system still treats the old claim as proof.
• An attacker obtains a valid provider session on a shared or compromised device.

None of these require a dramatic exploit. They are mostly boundary mistakes. The same concerns apply when testing with a disposable email address generator: a test address can validate delivery and state transitions, but it should not define production identity policy.

The tamp mail com spelling may appear in search terms or test fixtures, but it must not become a trusted account attribute by accident. Likewise, temp mailid is just input, not evidence that an address belongs to a person.

Separate the trust decisions

Use explicit signals rather than one overloaded flag:

provider_authenticated = the provider accepted the user's login
email_claim_present     = an email was returned
email_claim_verified    = the provider verified that email
local_account_linked    = the user explicitly linked this provider
recovery_eligible       = local policy allows recovery through this path

The exact names are not important. The separation is. A provider login can be accepted without granting automatic recovery rights. An email can be verified without allowing silent merging with an existing account.

For account linking, ask the user to authenticate the existing local account first. Then bind the provider identity to that account. I have found this boundary easier to explain in reviews than “merge by email and hope the provider semantics match.” For a related implementation detail, see binding email change links to the active session.

Also validate the OAuth protocol details: state for request correlation, nonce where OpenID Connect requires it, an exact redirect URI, a short-lived authorization code, and PKCE for public clients. These controls protect the callback, but they do not answer whether an email claim should authorize an account merge.

Safer implementation pattern

Store the provider subject (sub) together with the issuer. The pair is the provider identity key; an email address is an attribute that can be updated. Keep the original provider assertion, verification status, and timestamp available for audit decisions.

On first login:

1. Validate the issuer, audience, signature, nonce, and code exchange.
2. Look up the immutable issuer-plus-subject identity.
3. If it is new, create a pending local identity or start signup.
4. Require an explicit link or signup decision before joining an existing account.
5. Apply recovery policy separately from login policy.

When an email changes, do not silently use the new value to select a different account. Notify through the old trusted channel when possible, and require reauthentication for sensitive changes. Testing should cover both success and confusing failure states; my notes on privacy-aware login testing are a useful companion.

A review checklist

• Is the provider issuer allowlisted?
• Is the lookup keyed by issuer and subject, not email alone?
• Is email_verified checked with the provider's documented semantics?
• Can an OAuth login silently merge with a password account?
• Does account linking require proof of the existing account?
• Are state, nonce, PKCE, redirect URI, and code lifetime tested?
• Is recovery eligibility a separate policy decision?
• Are email changes bound to the active, recently authenticated session?
• Do logs avoid storing unnecessary email or token data?

OAuth is a strong building block, but it is not a universal identity oracle. Treat every claim as input to a policy, keep trust boundaries visible, and make account linking an intentional action. That gives users a flow that is still convenient, while making the risky assumptions much easier to find.