AuthN / AuthZ Design Review

Authentication proves who you are; authorization decides what you may do. Conflating them, or enforcing either in the wrong place, is the source of most access-control breaches. They are separate systems and must both be checked on every request.

Authentication: establishing identity

• Credential handling: passwords hashed with a slow, salted KDF (argon2/bcrypt/scrypt) — never fast hashes, never reversible. MFA for sensitive access.
• Session/token integrity: sessions must be unguessable, rotated on privilege change, invalidatable server-side, and bound to expiry. JWTs that can't be revoked are a liability for logout/compromise; verify signature, alg, audience, and expiry — reject alg: none.
• The auth boundary: every protected entry point re-establishes identity. "Authenticated once, trusted forever" within a session is how stolen tokens become persistent access.

Authorization: the part that's usually broken

• Enforce on every access, server-side, at the resource: the most common vulnerability class (IDOR / broken object-level authorization) is checking authentication but not whether this user may access this object. GET /orders/123 must verify 123 belongs to the caller.
• Deny by default: access is granted explicitly, never the absence of a deny. New endpoints should be locked until opened.
• Check at the right layer: authorization in the UI or API gateway alone is bypassable; enforce at the data/service layer closest to the resource.
• Function + object level: verify both that the user may perform the action and may touch the specific object/tenant.

Adversarial validation

• IDOR sweep: for every endpoint that takes an ID, can user A pass user B's ID and get B's data? Test horizontally (peer) and vertically (privilege escalation).
• Multi-tenant isolation: can tenant A reach tenant B's data via a shared cache, a missing tenant filter in a query, or a guessable identifier?
• Token abuse: replay an expired/revoked token, tamper with claims, swap alg, reuse a token after logout or password change — does any of it still work?
• Privilege transitions: does the session/token refresh privileges when a role is removed, or does a demoted user keep old powers until they log out?
• The forgotten path: admin endpoints, batch/export, internal APIs, and GraphQL resolvers often skip the authz check the main path has.

Non-obvious risks

• Authorization logic duplicated across services drifts; one service's stale check becomes the hole. Centralize the decision, enforce locally.
• Caching authorized responses can serve them to the wrong user if the cache key omits identity/tenant.
• "Soft delete" and "disabled" accounts often retain valid tokens; disabling must invalidate sessions.

Output structure

Deliver: the authN mechanism (credential storage, MFA, session/token integrity and revocation), the authZ model (deny-by-default, enforcement layer, object+function level), the IDOR/tenant-isolation test results, the privilege-transition handling, and the forgotten paths (admin, export, internal) explicitly verified.