Common Auth Architectures for SaaS Apps
Authentication is not a feature.
It’s infrastructure.
Get it wrong and you leak data, break sessions, or lock users out. Get it “almost right” and you spend months patching edge cases.
This is a breakdown of the most common auth architectures used in SaaS apps - how they work, where they fail, and what you should actually ship.
1. Monolithic Session-Based Auth
The classic setup.
- Server-rendered app
- Email + password
- Session stored in server memory or database
- Cookie sent to browser
Flow
- User submits credentials
- Server verifies password hash
- Server creates session
- Session ID stored in cookie
- Each request checks session
Pros
- Simple mental model
- Works well for traditional web apps
- Easy CSRF protection via same-site cookies
Cons
- Hard to scale horizontally (needs shared session store)
- Poor fit for SPAs and mobile
- OAuth and SSO get messy
- Multi-tenancy is usually bolted on later
When It Works
- Internal tools
- Admin dashboards
- Low-scale SaaS
Where It Breaks
When you add:
- Mobile apps
- APIs
- OAuth login
- Team accounts
- Cross-domain setups
Most SaaS apps start here. Very few should stay here.
2. Stateless JWT-Based Auth
Popular in API-first SaaS.
Instead of storing sessions on the server, you issue signed tokens (JWTs).
Flow
- User logs in
- Server returns signed JWT
- Client stores token (localStorage or cookie)
- Each request sends token
- Server verifies signature
Pros
- Stateless
- Scales easily
- Works across services
- Good for microservices
Cons
- Token revocation is hard
- Logout is not real (unless you track blacklists)
- Access token leakage = full compromise
- Refresh token rotation is tricky
Common Mistakes
- Long-lived JWTs
- Storing tokens in localStorage
- No rotation strategy
- No audience scoping
Security Reality
JWT does not mean secure.
It means portable.
Stateless auth increases architectural complexity, not reduces it.
3. SPA + API + Refresh Tokens
Modern SaaS standard.
You have:
- Frontend SPA (React, Vue, etc.)
- Backend API
- Access tokens (short-lived)
- Refresh tokens (rotated)
Flow
- Login → receive access + refresh token
- Access token expires quickly (5–15 min)
- Refresh token exchanges for new access token
- Refresh token rotated each time
Pros
- Secure short-lived access
- Good UX
- Mobile compatible
- OAuth-friendly
Cons
- Requires secure refresh storage
- Rotation logic must be correct
- Token replay attacks possible if misconfigured
- Requires serious edge case handling
You need to implement:
- Refresh token invalidation
- Replay detection
- Token binding (optional)
- Session tracking
- Device tracking (optional)
That’s not trivial.
4. OAuth Delegation (Google, GitHub, etc.)
You don’t manage passwords.
You rely on:
- :contentReference[oaicite:0]{index=0}
- :contentReference[oaicite:1]{index=1}
- :contentReference[oaicite:2]{index=2}
Flow
- Redirect to provider
- User consents
- Provider redirects back with code
- Exchange code for tokens
- Create or link account
Pros
- No password storage
- Lower liability
- Faster signup
- Better UX
Cons
- You still need sessions
- Account linking complexity
- Email verification logic
- Provider downtime risk
- Multi-provider identity merging issues
OAuth solves identity verification.
It does not solve session management.
5. SAML / Enterprise SSO
Required if you sell to companies.
Protocols:
- SAML
- OIDC
- SCIM (for provisioning)
Common providers:
- :contentReference[oaicite:3]{index=3}
- :contentReference[oaicite:4]{index=4}
- :contentReference[oaicite:5]{index=5}
Pros
- Enterprise-ready
- Centralized identity
- Required for SOC2-heavy buyers
Cons
- XML signatures are painful
- Debugging is brutal
- Metadata drift issues
- Customer misconfiguration chaos
If you sell to startups, ignore this.
If you sell to enterprises, you can’t.
6. Multi-Tenant Auth Architecture
Most SaaS apps are multi-tenant.
Auth must handle:
- Users
- Organizations
- Roles
- Permissions
- Invitations
- Domain-based login
- Tenant isolation
Architectural Options
A. Single Auth System, Tenant in DB
- user table
- org table
- membership table
Simple. Works for most apps.
B. Tenant-Aware Subdomains
- org1.app.com
- org2.app.com
Requires:
- Cookie scoping
- Cross-subdomain auth handling
- Correct CORS setup
C. Separate Auth per Tenant
Rare.
Used in:
- White-label SaaS
- Strict isolation setups
Common Failure
Auth implemented first. Multi-tenancy bolted on later.
That leads to:
- Leaky permissions
- Cross-tenant data access
- Broken invite flows
Authorization complexity grows faster than authentication complexity.
7. Microservices Auth
When your backend is split into services.
You need:
- Central auth issuer
- Service-to-service auth
- Internal token validation
Patterns:
- API Gateway validation
- mTLS between services
- Internal short-lived service tokens
If you skip this, you get:
- Token forwarding hacks
- Unverified internal requests
- Implicit trust boundaries
Most early SaaS apps over-engineer here.
8. Passwordless Auth
Magic links or OTP codes.
Flow
- Enter email
- Receive link or code
- Click to authenticate
Pros
- No password storage
- Lower support load
- Cleaner UX
Cons
- Email deliverability issues
- Link interception risks
- Harder device management
- Not enterprise-friendly
Works well for:
- B2C SaaS
- Low-security apps
- Early-stage products
9. WebAuthn / Passkeys
Modern, phishing-resistant auth.
Backed by platform authenticators.
Supported by:
- :contentReference[oaicite:6]{index=6}
- :contentReference[oaicite:7]{index=7}
- :contentReference[oaicite:8]{index=8}
Pros
- Phishing-resistant
- No passwords
- Strong cryptographic guarantees
Cons
- Complex implementation
- Device binding logic
- Recovery flows are hard
- Requires fallback
Most SaaS apps use this as a second factor.
Rarely as the only method.
The Real Problem
Auth is not one decision.
It’s layers:
- Identity verification
- Session management
- Token issuance
- Token rotation
- Revocation
- Authorization
- Multi-tenancy
- Audit logging
- Device management
- Enterprise SSO
DIY means implementing all of it.
AI-generated boilerplate handles 60%.
The remaining 40% is what breaks production.
What Most SaaS Builders Actually Need
If you’re a:
- Indie hacker
- Startup dev
- Agency builder
You likely need:
- Hosted login
- OAuth providers
- Secure sessions
- Multi-tenancy support
- Role-based access control
- Token rotation handled
- Enterprise SSO later
You do not need:
- Custom crypto
- Homegrown OAuth server
- Reinvented session store
Hosted Auth Architecture
Instead of building it, you delegate:
- Login UI
- OAuth flows
- Session handling
- Token lifecycle
- Multi-tenant support
- SSO integrations
Your app:
- Validates session
- Enforces permissions
- Ships features
You reduce:
- Attack surface
- Maintenance burden
- Compliance scope
You increase:
- Speed
- Security
- Focus
Why DIY Auth Is a Trap
You underestimate:
- Password reset flows
- Email verification
- Token replay attacks
- Refresh token rotation edge cases
- Logout invalidation
- Concurrent session handling
- Race conditions
- Tenant isolation bugs
Auth is simple until it’s not.
Then it’s a security incident.
Use Hosted Auth Instead
You want:
- Drop-in login
- OAuth out of the box
- Sessions handled correctly
- Multi-tenancy built in
- Enterprise-ready when needed
That’s what Simple Login provides.
Hosted auth for builders.
No edge-case roulette. No half-secure boilerplate. No months of patching.
Ship product. Not auth infrastructure.
Key Takeaways
- Session-based auth is simple but limited
- JWT stateless auth increases complexity
- OAuth solves identity, not sessions
- Multi-tenancy makes auth much harder
- Hosted auth lets you ship faster and safer