Authentication: The Front Door of Your Application
Authentication is how your application verifies user identity. It is the most security-critical feature — every other security measure depends on authentication working correctly. A bug in authentication can expose every user’s data.
This lesson covers testing authentication flows (login, registration, password recovery) and session management (how the application tracks who you are after login).
Login Flow Testing
Happy Path
Start with the obvious: valid credentials should work.
- Login with correct email and password
- Verify redirect to the correct page (dashboard, home, or the page they were trying to access)
- Verify the user’s name or avatar appears in the UI
- Verify session is created (check cookies in DevTools)
Invalid Credentials
| Test Case | Expected Behavior |
|---|---|
| Wrong password | Generic error: “Invalid email or password” (never reveal which is wrong) |
| Non-existent email | Same generic error as wrong password |
| Empty email | Validation error before submission |
| Empty password | Validation error before submission |
| SQL injection in email | No SQL error, generic validation message |
| XSS in email field | Input sanitized, no script execution |
| Extremely long email (1000+ chars) | Handled gracefully |
| Extremely long password (1000+ chars) | Handled gracefully |
Critical security note: The error message for wrong email vs. wrong password must be identical. Different messages allow attackers to enumerate valid accounts.
Brute Force Protection
Try logging in with wrong passwords repeatedly:
- After 3-5 failed attempts, does the system show a CAPTCHA?
- After 10+ attempts, is the account locked or rate-limited?
- Is there a cooldown period? How long?
- Does the lockout apply per IP, per account, or both?
- Can the lockout be bypassed by changing IP (using a VPN)?
Social Login (OAuth)
If the application supports Google, GitHub, Facebook login:
- Does the OAuth flow redirect correctly?
- What happens if the user denies permission?
- Is the email from OAuth matched to an existing account?
- What happens if the social provider is down?
- Can the user link/unlink social accounts?
Registration Flow Testing
Account Creation
- Valid registration with all required fields
- Duplicate email — should reject with clear message
- Password strength requirements — test just below each requirement
- Email verification — does the confirmation link work?
- Email verification link expiration — does it expire after a reasonable time?
- Registration with already-confirmed email — what happens?
Email Verification
- Register a new account
- Check that the verification email arrives
- Click the verification link — account should activate
- Click the same link again — should show “already verified” or similar
- Try to login before verifying — should show appropriate message
- Request a new verification email — does it invalidate the old link?
Password Recovery Testing
Forgot Password Flow
- Request password reset for a valid email
- Verify email arrives within reasonable time
- Click the reset link — should show password reset form
- Set a new password — should succeed
- Login with new password — should work
- Login with old password — should fail
- Click the reset link again — should be expired
Security Edge Cases
| Test | Expected |
|---|---|
| Reset for non-existent email | Same message as valid email (prevent enumeration) |
| Multiple reset requests | Only the latest link should work |
| Reset link after password change | Link should be invalidated |
| Reset link expiration (24h+) | Link should expire |
| Reset link format | Should be unpredictable (long random token) |
Session Management
Session Creation and Storage
After login, verify:
- A session cookie is created
- The cookie has
Secureflag (HTTPS only) - The cookie has
HttpOnlyflag (not accessible to JavaScript) - The cookie has
SameSiteattribute - The session ID is sufficiently long and random (at least 128 bits)
- The session ID changes after login (prevents session fixation)
Session Timeout
- Idle timeout: After X minutes of inactivity, the session expires. Test by waiting and then performing an action.
- Absolute timeout: After Y hours regardless of activity, the session expires. This limits damage from stolen sessions.
- Timeout behavior: When the session expires, what happens? Redirect to login? Show a modal? Lose unsaved work?
Advanced Authentication Testing
Concurrent Sessions
Test what happens when the same user logs in from multiple locations:
- Login on Browser A
- Login on Browser B with the same account
- Perform an action on Browser A — is the session still valid?
- Does the application limit concurrent sessions?
- If sessions are limited, which session is terminated — the old one or the new one?
- Is the terminated session notified?
Remember Me Functionality
If the login form has a “Remember me” checkbox:
- How long does the persistent session last? (Typically 30 days)
- Is a separate persistent token used (not the session cookie)?
- Can the user revoke all remembered sessions from their account settings?
- Does “Remember me” survive browser restart?
- Is the persistent token invalidated on password change?
Multi-Factor Authentication (MFA)
If the application supports MFA:
- Does it work with authenticator apps (TOTP)?
- Does it work with SMS codes?
- What happens with an expired code?
- What happens with a wrong code 3+ times?
- Can MFA be bypassed by manipulating the request?
- Are backup codes provided and do they work?
- What happens if the user loses their MFA device?
Account Lockout Testing
- Trigger account lockout (multiple failed login attempts)
- Verify the lockout duration
- Can the user still reset their password while locked out?
- Does the lockout counter reset after successful login?
- Is the lockout per IP address, per account, or both?
Exercise: Authentication Security Audit
Perform a complete authentication audit on a web application:
- Registration: Create an account, try duplicates, test email verification
- Login: Test valid/invalid credentials, check error messages for enumeration leaks
- Session: Inspect cookies for security flags (Secure, HttpOnly, SameSite)
- Timeout: Wait for session expiration, verify behavior
- Password reset: Complete the flow, verify link expiration and old-password invalidation
- Concurrent sessions: Login from two browsers simultaneously
- Logout: Verify session destruction — press back button after logout, try to access authenticated pages
Document findings:
| Area | Test | Finding | Risk |
|---|---|---|---|
| Login | Error messages | Different for wrong email vs. wrong password | High (enumeration) |
| Session | Cookie flags | Missing HttpOnly flag | High (XSS can steal session) |
| Password reset | Link expiration | Link works after 7 days | Medium |
| Logout | Back button | Shows cached authenticated page | Medium |
Logout Testing
Logout is often under-tested:
- Click logout — verify redirect to login page
- Press browser back button — should NOT show authenticated content
- Try to access an authenticated URL directly — should redirect to login
- Check that session cookie is deleted or invalidated
- Check that server-side session is destroyed (not just cookie deletion)
- In a separate tab still open — what happens when you try to perform an action?
Key Takeaways
- Authentication is the most security-critical feature — test it exhaustively
- Login error messages must be generic to prevent account enumeration
- Always verify session cookies have Secure, HttpOnly, and SameSite flags
- Test session timeout both for idle and absolute durations
- Password reset links must expire and invalidate after use
- Session IDs must regenerate after login to prevent session fixation
- Logout must destroy the session server-side, not just delete the cookie
- Test concurrent sessions, MFA, and account lockout as part of authentication testing