The SaaS auth checklist: 40 things to verify before you go to market

Auth is one of those areas where the gaps only become visible when something goes wrong — a breach, a security audit, or an enterprise customer's questionnaire that asks about capabilities you assumed were in place but never actually built. This checklist covers the 40 items we see most commonly missed or misconfigured on SaaS auth systems. Work through it before launch, before your first enterprise deal, and as a periodic review framework.

Password Policy

  • Minimum length is 12 characters (not 8). NIST SP 800-63B recommends at least 8 but sets no maximum, and 12+ is now the practical baseline.
  • Maximum length supports at least 64 characters. Password managers generate long passwords; truncating them silently is a serious bug.
  • Passwords are not rejected based on character composition rules (no "must include a number"). Composition requirements reduce entropy and frustrate users.
  • Passwords are checked against the HIBP Pwned Passwords database at registration and on login. Breached passwords are rejected or flagged.
  • Passwords are stored using Argon2id, bcrypt (cost factor ≥12), or scrypt. SHA-256 or MD5 password storage is not acceptable.

MFA Enrollment

  • TOTP (authenticator app) is supported as an MFA factor. SMS is available but users are encouraged toward TOTP.
  • FIDO2/WebAuthn hardware key enrollment is supported, or is on the roadmap with a clear timeline.
  • MFA enrollment can be made mandatory at the org level by an admin, not just optional per-user.
  • MFA backup codes are generated at enrollment and stored as one-way hashed values. Each backup code can only be used once.
  • MFA removal from an account generates an email notification to the account owner and is logged in the audit trail.

Session Management

  • Session tokens are cryptographically random (32+ bytes from a CSPRNG). They are not sequential, predictable, or derived from user data.
  • Sessions are invalidated server-side on logout. Client-side cookie deletion alone is not sufficient.
  • All sessions for a user are invalidated when their password changes or when an admin forces a sign-out.
  • Session lifetime is configurable — short-lived sessions (1 hour) for sensitive orgs, longer for standard users, with a hard maximum regardless of activity.
  • Concurrent session limits are enforceable at the org level (e.g., allow only 3 active sessions per user).
  • A "Sign out all devices" option is available from the user's account settings page.

Token Security

  • Access tokens have a short lifetime (15–60 minutes). Refresh tokens are used for obtaining new access tokens.
  • Refresh token rotation is enabled: each refresh issues a new token and revokes the old one. Reuse detection terminates the token family.
  • JWTs are signed with RS256 or ES256 (asymmetric). HS256 with a shared secret is not used when tokens are validated by multiple services.
  • The JWKS endpoint is available and the signing key has a kid field. Key rotation procedure is documented and tested.
  • Access tokens contain the minimum necessary claims. Profile data (name, email) is not embedded in tokens sent to APIs.

Audit Logging

  • Every login attempt (success and failure) is logged with timestamp, user identifier, IP, and user agent.
  • Every admin action (role change, SSO config change, member removal) is logged with the actor's identity.
  • Audit logs are immutable: they cannot be modified or deleted via the application interface or normal database permissions.
  • Audit logs are retained for at least 90 days accessible (12 months archived). Log retention policy is documented.
  • Enterprise customers can access their own org's audit logs via the admin UI or an API export.

GDPR and Data Controls

  • User deletion is a complete deletion: all PII is removed from the primary database, all backups have a documented retention window before PII purges, and all derived data is cleaned up.
  • Data export (GDPR right to portability) produces a complete export of the user's data in a machine-readable format.
  • Consent for non-essential cookies and tracking is captured with a proper consent mechanism — not a pre-ticked box or a notice-only banner.
  • Data processing agreement (DPA) is available for customers who request it, covering sub-processors and transfer mechanisms.

SSO Support

  • SAML 2.0 SSO is supported with self-service configuration for enterprise customers. Customers do not need to contact support to configure their IdP.
  • OIDC/OAuth SSO is supported in addition to SAML. Azure AD, Okta, and Google Workspace have been tested as IdPs.
  • SSO enforcement (blocking password login for SSO-configured orgs) is available and configurable by org admins.
  • JIT provisioning creates users automatically on first SSO login with correct role assignment from IdP attributes.
  • SCIM provisioning (or at minimum, webhook-based deprovisioning) is available so IdP-managed user deactivation reflects in your app.

Rate Limiting

  • Login endpoints are rate limited per account (email). Failed attempts trigger progressive backoff, not just a fixed window.
  • Password reset, email verification, and MFA code endpoints are rate limited to prevent enumeration and OTP brute force.
  • Rate limiting responses return Retry-After headers so clients can back off correctly.
  • Rate limits are not so aggressive that legitimate users with slow networks or retrying clients are blocked.

Breach Detection

  • Unusual login patterns (new device, new country, impossible travel) generate user-visible notifications by email.
  • A security alert email is sent when a new MFA factor is added, removed, or when a password is changed.
  • An incident response runbook exists for auth-related security events (account takeover, token compromise, key compromise).
  • A security contact email and responsible disclosure policy is publicly accessible.

Pentest Coverage

  • A penetration test has been conducted by an independent security firm, or is scheduled before reaching significant user scale.
  • OWASP Top 10 items have been verified against the auth system specifically: injection, broken auth, sensitive data exposure, broken access control, security misconfiguration.
  • Session fixation, CSRF, and clickjacking protections are in place and have been verified in testing.
  • Findings from the last security review are tracked with remediation status. Critical and high findings have a documented SLA for resolution.

This list is not exhaustive — auth security is a moving target and new attack vectors emerge regularly. But completing every item here puts your auth system in a meaningfully better position than the majority of SaaS products at the same stage. The items under Session Management and Token Security are the most commonly missed. The items under SSO and GDPR are the most commonly discovered during enterprise sales due diligence. If you are working toward SOC 2 Type II, the Audit Logging section is where auditors spend the most time.

// Quick check: are your auth cookies set correctly?
// Run this in your browser console after logging in
document.cookie.split(';').forEach(c => {
  const [name] = c.trim().split('=');
  console.log(name, '— visible to JS (should be false for session cookies)');
});
// If your session cookie is visible here, you're missing HttpOnly
The single highest-leverage item if you can only do one: enable Argon2id or bcrypt with a sufficient cost factor and implement refresh token rotation. A database breach with properly hashed passwords is painful but recoverable. A breach with MD5 or SHA-1 hashed passwords compromises every user account within hours. Rotate your signing keys and your understanding of what "secure" means for password storage every year.
← Back to blog Try Bastionary free →