Authentication Is a Workflow, Not a Login Button

The failure

“Login works for me.”

Meanwhile:

• new users cannot register
• sessions die on refresh
• logout leaves protected pages reachable
• OAuth start never leaves the app

Authentication is not a button. It is a workflow with multiple failure modes that still leave the marketing shell looking healthy.

The workflow

A useful minimum set:

1. Register (or invite accept)
2. Login with valid credentials
3. Reject invalid credentials
4. Session persistence across reload
5. Logout clears access
6. Anonymous users cannot open protected UI
7. Password-reset entry still reachable
8. OAuth entry still reachable (if you offer it)

Endia’s authentication example encodes 8 checks along these lines.

Why the app can “load” while auth is broken

Shell routes, public landing pages, and CDN-cached assets do not exercise session cookies, redirect loops, or RBAC. A green deploy of / says nothing about /settings after cookie expiry.

Coverage limits (read carefully)

LIMITED / honest boundaries for Endia’s public auth demo:

• Controlled fixture — not your IdP
• OAuth is entry-path only; no live provider completion
• No MFA coverage claimed
• No auth-bypass teaching demos

If your product requires MFA or full OAuth round-trips, record those flows against your own preview — do not infer them from the public example.

How to test it

Drive the workflow on the preview URL. Assert both positive access and negative denial. A login success without a protected-route denial check is half a test.

Checklist

• [ ] List every auth state transition you rely on in production.
• [ ] Include at least one “should be denied” assertion.
• [ ] Re-run after cookie, CSRF, or middleware changes.
• [ ] Do not claim OAuth/MFA coverage you have not recorded.