Authentication establishes who is interacting with a system. It begins before a login request reaches application logic and continues through credential checks, session creation, renewal, recovery, and sign-out. A working login screen proves only that one path completes. It does not show whether every identity path applies the same rules.
Where authentication appears
Authentication is rarely contained in one function. A web product may combine a password form, a social identity provider, email links, API keys, and service-to-service credentials. Each path creates or accepts evidence of identity. The system then translates that evidence into a session or token used by later requests.
An audit of vibe-coded software maps those paths before judging their implementation. Generated features can add a second login mechanism without reusing the checks applied to the first. The visible result still works, while recovery, token expiry, or administrative access follows a separate set of assumptions.
| Authentication path | Evidence to inspect | Typical boundary |
|---|---|---|
| Password login | Hashing, rate limits, error responses | Credential check |
| Identity provider | Callback validation, account linking | External identity |
| Password reset | Token lifetime, reuse, account change | Recovery flow |
| API access | Key storage, rotation, revocation | Machine identity |
Authentication and authorization are different
Authentication answers who the actor is. Authorization decides what that actor may do. Combining the two creates gaps: a route may correctly require a logged-in user but never verify whether that user owns the requested record. An audit traces both decisions independently for every sensitive action.
The review follows identity state through the complete request lifecycle:
- Entry: Identify every way a person or service can present credentials.
- Verification: Check where credentials, provider responses, or signed tokens are validated.
- Session: Trace how trusted state is created, stored, renewed, and ended.
- Recovery: Review reset and account-linking paths as authentication paths in their own right.
- Failure: Confirm that rejected attempts do not reveal account details or leave partial state behind.
What an audit checks
The audit compares each path against the same identity rules. It checks whether security-sensitive values come from controlled secrets management, whether expiry is enforced by the server, and whether a revoked credential stops working everywhere it is accepted. It also reads tests to see whether they cover rejection and recovery rather than only successful login.
This is where shipping discipline matters. Authentication code can look complete because the main screen works, even when an alternate callback or stale session bypasses the intended boundary. The useful output is a map of identity paths, the rule each path enforces, and any path that establishes trust differently from the rest.
Evidence after repair
A repaired flow needs evidence at the boundary, not only a manual login. Tests should show that invalid credentials stay invalid, expired state is rejected, recovery tokens cannot be reused, and authentication does not silently grant broader access. Logs should record security-relevant events without storing credentials or tokens. Together, those checks make identity behaviour inspectable after the audit ends.
