Engineering Auth Authentication

Authentication Strategy Prompt

Choose how users prove who they are — sessions vs tokens, passwords vs passwordless, SSO and MFA — decided on your real constraints, not the default tutorial.

Overview

Authentication is hard to change once users exist, so the choice deserves more than copying a tutorial. This prompt works the decision on trade-offs: session vs token, where credentials live, whether to support SSO and MFA, how it behaves across web/mobile/API clients, and the recovery and revocation paths — ending in a chosen strategy with its reasoning, not a default.

How to use this resource

  1. Define your auth constraints

    Note your clients (web, mobile, API), where credentials would live, and whether you need SSO and MFA. The strategy is decided on these real constraints, not a default.

  2. Open this resource in Role Prompt Generator

    Load the prompt into Role Prompt Generator and fill in your context. It frames the session-vs-token, password-vs-passwordless, and recovery decisions as a worked trade-off.

  3. Review the chosen strategy

    Read the recommended approach with its reasoning, the client behavior, and the recovery and revocation paths, checking each against your constraints.

  4. Tighten the assumptions and re-run

    Where a constraint shifts the trade-off, such as a new client type or compliance rule, adjust the context and regenerate so the strategy fits before you build on it.

Why This Works

  • Auth is expensive to change later, so the upfront trade-off matters
  • Designing revocation and recovery early avoids the classic auth gaps
  • Multi-client thinking prevents the mobile path that weakens the web path

Best for

  • Greenfield products choosing their auth foundation
  • Teams tempted to copy an auth tutorial wholesale
  • Products spanning web, mobile, and API clients

Not for

  • Reviewing JWT implementation specifics — use the JWT Security Review Prompt
  • Designing roles and permissions — use the RBAC Design Prompt

Use cases

  • Choosing an auth approach for a new product
  • Deciding between sessions and tokens on real trade-offs
  • Designing recovery and revocation up front

FAQ

How does this prompt decide sessions vs tokens instead of just defaulting to one?

Decision 1 (MECHANISM) forces a session-based vs token-based choice tied to THIS product's clients, and a RULE bars deciding on 'what's trendy.' Fill in your web/mobile/API mix and sensitivity, run it in ChatGPT, Claude, or Gemini, and it returns a mechanism with the trade-off reasoning. Role Prompt Generator structures that argument; the architecture call stays yours.

Why does the strategy include account recovery and revocation instead of just the login method?

Decision 6 (LIFECYCLE) treats account recovery, session expiry, and token/credential revocation as part of the strategy, and a RULE states recovery and revocation are 'not an afterthought.' The output pairs the chosen approach with an explicit recovery/revocation design, so the paths people forget get decided up front rather than patched after users exist.

When should I reach for a different resource than this one for auth?

Use it for the strategy layer — mechanism, credentials, SSO, MFA, multi-client, lifecycle. Its notFor deliberately skips JWT implementation specifics (pointing to the JWT Security Review Prompt) and roles/permissions (the RBAC Design Prompt). It also won't verify your final design; the security review and build decisions stay with you after you run the generated prompt.

More resources from Role Prompt Generator

Resources that pair well

Related tools

Projects that use this resource

Workflows that use this resource

Guides for this resource

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