Broken authentication can open the door before authorization even starts.
We audit the login, session, and token paths that decide whether the right user lands in the right account with the right tenant and role context.
Authentication has to survive real user state, not just a successful login.
In SaaS, broken authentication usually shows up when a session is stale, a token is misused, a reset flow is too trusting, or the system lands the user in the wrong tenant after login.
Broken authentication often becomes broken access control when stale identity is still trusted after login.
Tenant isolation fails when login establishes the wrong organization or fails to clear previous tenant context.
Authorization reviews usually expose the next failure after authentication because the wrong session still carries access.
The audit checks the boundary the same way customers hit it: by logging in, switching state, and comparing the returned behavior.
The login and session behaviors that matter
These are the request-level checks that tell us whether authentication is still trustworthy after login, token rotation, or account switching.
Session handling
Check whether sessions expire, rotate, and invalidate the way the product expects.
Token lifecycle
Review token issuance, revocation, refresh, and stale token behavior across login flows.
Auth callback assumptions
Test whether callback handlers trust the wrong identity or return path information.
Account switching
Validate whether switching users, tenants, or organizations leaks stale context.
Password reset flow risk
Check reset token lifetime, reuse, and whether the flow accepts the wrong account state.
Stale sessions
Verify that logged-out or expired sessions cannot continue to reach protected paths.
Role or tenant context after login
Confirm that the authenticated identity lands in the correct tenant and role scope.
Audit evidence around auth events
Review whether the product can prove who logged in, from where, and through which path.
Where broken authentication usually hides
The failure often looks small in the UI, but the security impact can be large once stale identity is still trusted by the backend.
Expired session still works
A stale session token can still reach a protected endpoint after the user should have been signed out.
Refresh token reuse
A reused refresh token can mint a new session even after revocation or rotation.
Password reset token replay
A reset link or token can be used more than once or after the intended window.
Login callback trusts the wrong identity
The callback exchanges or session assignment step accepts a user context that should not be trusted.
Account switch leaves stale tenant state
The user switches accounts, but tenant or role context from the previous session still bleeds through.
Logout does not invalidate access
The UI says logged out, but the API still accepts the token or cookie.
Findings that engineering can replay and close.
The output focuses on the exact request and response behavior, the broken assumption, the impact, and the fix path so your team can validate the repair later.
- Request and response evidence
- Severity and business impact framing
- Reproduction notes
- Remediation guidance
- Retest notes
- Buyer-friendly summary
Broken auth is usually the first step before authorization failures.
If login lands the user in the wrong account, authorization and tenant isolation cannot be trusted either. This audit helps prove where the chain starts to break.
- Broken auth can lead to broken access control.
- Wrong tenant context after login can expose customer data.
- Token and session handling mistakes widen the attack surface.
- The same request-level proof model carries into authorization and tenant isolation reviews.
Follow the same boundary into the rest of the audit cluster
API Authorization Audit
Request-level checks for actor, tenant, role, and object mismatches after login.
Open pageBroken Access Control Audit
Control paths where a successful login still allows the wrong action or object access.
Open pageSecurity Lab
Controlled proof scenarios that show how request-level boundary failures look in practice.
Open pageTest the authentication boundary before it becomes an access problem.
If login, session handling, or token state is weak, the next authorization check is already on shaky ground.