Guides

Adding Google and Amazon sign-in to a B2B SaaS

July 2026

"Continue with Google" removes the highest-friction step of signing in, and for products sold to businesses it is close to table stakes: most of your buyers live in Google Workspace. Login with Amazon shows up less often, which is exactly why offering it can differentiate you with teams that live in the Amazon ecosystem. The buttons look identical on a login page. The engineering behind them is not.

The two flows are not the same

Google implements OpenID Connect: you receive an ID token you verify against Google's published keys, with a nonce binding the token to the session that requested it. Amazon implements plain OAuth 2.0: there is no ID token, so you exchange the authorization code for an access token and then call Amazon's profile endpoint to learn who signed in. If your integration layer assumes every provider is OIDC, Amazon is where that assumption breaks.

Decisions that matter more than the OAuth dance

Account matching. In B2B, the sane rule is that a social login signs into an account that already exists with that verified email, and anything else is rejected with a clear error. Auto-creating accounts from any Google sign-in turns your tenant boundary into a suggestion.

Email trust. You are trusting the provider's word that the user owns the email address. That is a threat-model decision worth writing down. A profile that arrives without an email should fail closed, not fall through to a guess.

MFA interactions. If an account has a second factor enrolled, decide explicitly whether a social login satisfies it, prompts for it, or is refused. Silently bypassing MFA because the login came from Google is the kind of decision that reads very badly in a post-incident review.

State handling. The state parameter must be a single-use, expiring server-side record, consumed on the callback. It is your CSRF defense for the whole flow, and "we compare it to a cookie" is not the same thing.

The checklist

• Register the OAuth client with each provider, one redirect URI per environment.
• Keep client secrets in a secrets manager, never in environment files that get copied around.
• Verify Google ID tokens against Google's keys, including nonce and audience.
• Exchange and call Amazon's profile endpoint server-side only.
• Map provider identities to existing verified accounts; fail closed on anything unknown.
• Audit-log every social sign-in, success and failure, with the provider recorded.

Our recommendation