What This Template Is For
Authentication is the front door of every product. A poorly designed auth flow creates friction that drives users away before they ever experience your core value. A weak auth flow creates security vulnerabilities that put your users and your company at risk. This template helps you design authentication flows that balance security requirements with user experience goals.
Most teams treat authentication as a purely technical concern and hand it off to engineering without a product spec. The result is an auth flow that works for engineers but frustrates users: unclear error messages, unnecessary steps, no recovery paths. Product managers who invest in auth flow design catch usability issues before they ship and reduce support tickets related to account access.
This template covers the full auth lifecycle: registration, login, session management, account recovery, and step-up authentication. It works for B2B SaaS, B2C apps, and internal tools. If you need to go deeper on the technical architecture, the Technical PM Handbook covers infrastructure planning in detail. For mapping the broader user journey around auth, the customer journey map template provides a complementary framework. If you are defining role-based permissions after authentication, see the access control template.
How to Use This Template
- Start with the User Journey Map section. Walk through every path a user takes to access your product.
- Define your security requirements using the Security Requirements Matrix. These constraints shape the flow design.
- Map each auth flow step by step using the Flow Specification table.
- Document error states and recovery paths. These are the flows users actually experience most often.
- Use the implementation checklist to hand off to engineering with clear acceptance criteria.
The Template
Part 1: Auth Strategy Overview
| Field | Details |
|---|---|
| Product Name | [Your product] |
| Auth Model | [Email/password, SSO, Social login, Passwordless, Hybrid] |
| Target Users | [Consumer, SMB, Enterprise, Internal] |
| Security Tier | [Standard, Elevated, High-Security] |
| Compliance Requirements | [SOC 2, GDPR, HIPAA, PCI DSS, None] |
| Session Duration | [Hours/days for idle timeout and absolute timeout] |
| MFA Requirement | [Optional, Encouraged, Required for all, Required for admins] |
Part 2: Auth Methods Supported
| Method | Supported | Primary/Secondary | Notes |
|---|---|---|---|
| Email + Password | Yes / No | ||
| Magic Link | Yes / No | ||
| Social Login (Google) | Yes / No | ||
| Social Login (GitHub) | Yes / No | ||
| Social Login (Apple) | Yes / No | ||
| SSO (SAML) | Yes / No | ||
| SSO (OIDC) | Yes / No | ||
| Passkey / WebAuthn | Yes / No | ||
| Phone / SMS | Yes / No | ||
| MFA (TOTP) | Yes / No | ||
| MFA (Hardware Key) | Yes / No |
Part 3: User Journey Map
Map every path a user takes to authenticate. Include both happy paths and failure paths.
Registration Flow.
| Step | Screen / Action | User Input | System Action | Success Path | Failure Path |
|---|---|---|---|---|---|
| 1 | [Landing page CTA] | [Click "Sign Up"] | [Show registration form] | Step 2 | - |
| 2 | [Registration form] | [Email, password, name] | [Validate inputs, check for existing account] | Step 3 | [Show inline errors] |
| 3 | [Email verification] | [Click link in email] | [Verify token, activate account] | Step 4 | [Show expired/invalid link] |
| 4 | [Onboarding] | [Complete setup] | [Create workspace, set defaults] | [Dashboard] | - |
Login Flow.
| Step | Screen / Action | User Input | System Action | Success Path | Failure Path |
|---|---|---|---|---|---|
| 1 | [Login page] | [Email, password] | [Validate credentials] | Step 2 or Dashboard | [Show error, increment attempt counter] |
| 2 | [MFA prompt (if enabled)] | [TOTP code] | [Validate code] | Dashboard | [Show invalid code error] |
Account Recovery Flow.
| Step | Screen / Action | User Input | System Action | Success Path | Failure Path |
|---|---|---|---|---|---|
| 1 | [Forgot password page] | [Email] | [Send reset email (always show success)] | Step 2 | - |
| 2 | [Reset email] | [Click reset link] | [Validate token, show new password form] | Step 3 | [Show expired link page] |
| 3 | [New password form] | [New password] | [Update password, invalidate sessions] | [Login page with success message] | [Show validation errors] |
Part 4: Security Requirements Matrix
| Requirement | Specification | Rationale |
|---|---|---|
| Password Policy | [Min length, complexity, breach list check] | [Why this policy level] |
| Rate Limiting | [Max attempts per IP per minute] | [Prevents brute force] |
| Account Lockout | [After N failed attempts, lock for M minutes] | [Balances security and usability] |
| Session Timeout | [Idle: X hours, Absolute: Y hours] | [Compliance or security posture] |
| Token Storage | [httpOnly cookie / localStorage / sessionStorage] | [XSS and CSRF mitigation strategy] |
| CSRF Protection | [SameSite cookies, CSRF tokens, origin check] | [Prevents cross-site request forgery] |
| Encryption | [TLS 1.2+, bcrypt/Argon2 for passwords] | [Data protection in transit and at rest] |
| Audit Logging | [Log all auth events with IP, user agent, timestamp] | [Compliance and incident investigation] |
Part 5: Error States and Recovery
Document every error a user can encounter during authentication. Vague error messages ("Something went wrong") create support tickets. Specific, helpful error messages create trust.
| Error Condition | User-Facing Message | Recovery Action | Security Note |
|---|---|---|---|
| Invalid email format | "Enter a valid email address" | Highlight field, show format hint | - |
| Wrong password | "Incorrect email or password" | Show "Forgot password?" link | Do not reveal which field is wrong |
| Account locked | "Too many attempts. Try again in 15 minutes" | Show lockout timer, offer reset | Rate limit still enforced |
| Unverified email | "Verify your email to continue" | "Resend verification email" button | - |
| Expired reset link | "This link has expired" | "Request a new reset link" button | - |
| SSO domain mismatch | "Sign in with your company's SSO" | Redirect to SSO provider | Hide password form for SSO-only domains |
| MFA code invalid | "Invalid code. Please try again" | Show remaining attempts | Lock after 5 failures |
| Session expired | "Your session has expired. Please sign in again" | Redirect to login, preserve intended URL | Clear all session data |
Part 6: Implementation Checklist
- ☐ Registration form validates email format and password strength client-side
- ☐ Server-side validation matches client-side rules (never trust client only)
- ☐ Password hashing uses bcrypt or Argon2 with appropriate cost factor
- ☐ Email verification tokens expire after 24 hours
- ☐ Password reset tokens expire after 1 hour and are single-use
- ☐ Rate limiting is applied to login, registration, and password reset endpoints
- ☐ Account lockout triggers after N consecutive failures
- ☐ Error messages do not reveal whether an email exists in the system
- ☐ Session tokens are stored in httpOnly, Secure, SameSite cookies
- ☐ All auth endpoints are served over HTTPS only
- ☐ Audit log captures: event type, timestamp, IP address, user agent, result
- ☐ "Remember me" option extends session but not security-sensitive operations
- ☐ Logout invalidates server-side session (not just client token)
- ☐ CSRF protection is enabled on all state-changing auth endpoints
- ☐ Social login handles account linking (same email, different provider)
- ☐ SSO configuration page allows admins to set up SAML/OIDC without engineering help
Filled Example: SaaS Project Management Tool
Auth Strategy Overview
| Field | Details |
|---|---|
| Product Name | TaskFlow |
| Auth Model | Hybrid: Email/password + Google SSO + Enterprise SAML |
| Target Users | SMB and Enterprise product teams |
| Security Tier | Elevated (handles project data, integrations with code repos) |
| Compliance Requirements | SOC 2 Type II |
| Session Duration | Idle: 8 hours, Absolute: 30 days |
| MFA Requirement | Optional for free/pro plans, Required for Enterprise admins |
Registration Flow (Filled)
| Step | Screen / Action | User Input | System Action | Success Path | Failure Path |
|---|---|---|---|---|---|
| 1 | Marketing page hero CTA | Click "Start Free Trial" | Show registration form with Google SSO button at top | Step 2 | - |
| 2 | Registration form | Name, work email, password (8+ chars, 1 uppercase, 1 number) | Validate inputs. Check if email domain has SSO configured | Step 3 (email) or redirect to SSO | Inline validation errors. If SSO domain: "Your company uses SSO. Sign in with [Company] SSO" |
| 3 | Email verification | Click link (valid 24h) | Verify token. Create user record. Auto-detect organization from email domain | Step 4 | "This link has expired. Resend verification email" with one-click resend |
| 4 | Onboarding wizard | Team name, invite 2 teammates (optional), select use case | Create workspace. Send invite emails. Set default views based on use case | Dashboard with "Welcome" tour | Skip button available. No forced invites |
Error Messages (Filled)
| Scenario | Message | Recovery |
|---|---|---|
| Email already registered (email/password) | "An account with this email already exists. Sign in or reset your password." | Links to login and password reset |
| Email already registered (SSO domain) | "Your company uses TaskFlow with SSO. Sign in with [Company SSO]." | Button: "Sign in with SSO" |
| Weak password | "Password needs at least 8 characters, one uppercase letter, and one number" | Real-time validation as user types |
| Google SSO: email not in allowed domain (Enterprise) | "Your email domain is not authorized for this organization. Contact your admin." | Link: "Request access" (sends email to workspace admin) |
| Too many login failures (5 in 10 min) | "Too many sign-in attempts. Try again in 15 minutes, or reset your password." | Show countdown timer. "Reset password" link |
Common Mistakes to Avoid
- Revealing account existence in error messages. "No account found for this email" tells an attacker which emails are registered. Always use a generic message like "Incorrect email or password" for credential errors. The password reset flow can confirm email existence (since the user owns the email), but the login flow should not.
- Treating auth as engineering-only scope. Auth flow design directly impacts activation rate, support volume, and security posture. PMs should own the user journey, error messages, and recovery paths. Engineering owns the cryptographic implementation and infrastructure.
- Skipping the account linking scenario. A user registers with email/password, then later tries to sign in with Google using the same email. Without account linking logic, they get a confusing error or a duplicate account. Map this scenario explicitly.
- Building auth from scratch. Unless your product has unusual auth requirements, use an auth provider (Auth0, Clerk, WorkOS, Supabase Auth). The Technical PM Handbook covers build-vs-buy decisions for infrastructure components like auth.
- Ignoring the enterprise SSO requirement. Enterprise buyers expect SAML SSO. If you plan to sell to companies with 100+ employees, design your auth model to support SSO from day one. Retrofitting SSO into an email/password system is a 2-4 month engineering project.
Key Takeaways
- Design auth flows from the user's perspective first, then layer in security requirements
- Document every error state with a specific, helpful message and a recovery path
- Use the "email-first" pattern to handle multiple auth methods without confusing users
- Never reveal account existence through login error messages
- Plan for SSO early if you sell to Enterprise customers
- Use the implementation checklist to ensure nothing is missed in the handoff to engineering
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use