Engineering

OAuth & SSO Integration Prompt

Integrate OAuth/SSO without the footguns — the right flow for your client, state and PKCE, token handling, account linking, and the provider-edge cases that break logins.

Overview

OAuth is easy to wire up and easy to wire up insecurely. This prompt plans the integration: the correct flow for your client type (auth code + PKCE, not implicit), CSRF protection via state, where tokens live, how provider accounts link to local users, and the edge cases that cause real outages — email changes, revoked grants, and the user who signs up with Google then tries a password.

Why This Works

Auth code + PKCE vs implicit is the choice most insecure integrations get wrong
Verified-email account linking closes a common account-takeover path
The provider edge cases are where SSO integrations break in production

Best for

Products adding social or enterprise SSO
Teams new to OAuth's security details
Apps mixing SSO and password accounts

Not for

Choosing whether to use SSO at all — use the Authentication Strategy Prompt
Reviewing an existing JWT — use the JWT Security Review Prompt

Use cases

Adding 'Sign in with Google/GitHub/etc.' safely
Planning account linking between SSO and local accounts
Avoiding the OAuth flow and token mistakes that cause breaches

Customize This Resource

Opens this resource in the related tool with the fields pre-filled. Customize role, tone, and behavior rules — then generate your prompt.

Prompt Template

ROLE
You are planning an OAuth / SSO integration securely and completely.

INPUT
The integration:
[Provider(s), client type (web/SPA/mobile/server), and your existing accounts]

PLAN THE INTEGRATION
1. FLOW: the correct flow for this client (authorization code + PKCE for public clients; never implicit) — with why.
2. CSRF & REPLAY: state parameter, PKCE, and nonce handling to prevent CSRF and replay.
3. TOKEN HANDLING: what you store (access/refresh/ID), where, and how refresh and expiry are handled.
4. ACCOUNT LINKING: how a provider identity maps to a local user — new account, link to existing, and the verified-email rule that prevents account takeover.
5. SCOPES: the minimum scopes requested, and why each is needed.
6. EDGE CASES: provider email change, revoked grant, deactivated provider account, and the mixed-method user (signed up with SSO, later tries password).

RULES
- Public clients use auth code + PKCE — never the implicit flow.
- Only link accounts on a verified email match, or you enable takeover.

OUTPUT
The flow choice with rationale, the token and linking design, and how each edge case resolves.

Related Resources

Explore more resources that work well with this one.

Related Tools

Multi-Step Prompt Builder

Tip: Save time by exploring related resources and tools that integrate with this workflow.

Explore all resources