Full Stack Authentication & Authorization Security

Separate identity from permission

Authentication establishes a user's identity. Authorization decides whether that identity may perform a particular operation on a particular resource. A successful login does not grant access to every account, tenant or admin route.

A request-level policy

GET /api/me/profile
  authenticate session
  load profile for authenticated user ID
  return allowed fields

PATCH /api/courses/:id
  authenticate session
  authorize course-edit permission for this resource/tenant
  validate allowed fields
  update through a parameterized query
  record a safe audit event

Never trust a user_id, role or tenant supplied in a request body as proof of authority. Test with two separate users and verify that changing a resource identifier cannot access another user's record. Hiding an admin button is not server authorization.

Session and token tradeoffs

An opaque server-managed session is a reasonable default for many browser applications. A Secure, HttpOnly cookie restricts transport and script access, while SameSite and an appropriate anti-CSRF design address cross-site request risks. HttpOnly does not make an application immune to XSS, and SameSite is not a complete authorization system.

A JWT is signed data, not automatically encrypted. Validate its signature, expected algorithm, issuer, audience and time constraints with a maintained library. Define logout, expiry, revocation and key-rotation behavior rather than choosing JWT solely to avoid thinking about sessions. Browser-readable token storage has exposure tradeoffs.

Password and recovery flow

Use a maintained password-hashing implementation, HTTPS, rate controls and generic login/recovery messages that do not expose whether an account exists. Recovery tokens need expiry and single-use handling. Do not log passwords, cookies or bearer tokens. Privileged operations may require stronger authentication and reauthentication.

Verification matrix

1. Unauthenticated request: denied.
2. Authenticated user with no required permission: denied.
3. Permitted user requesting another tenant's resource: denied.
4. Expired or revoked session/token: denied.
5. Valid authorized request: succeeds and returns only permitted fields.

Begin implementation from current framework and security guidance, and review the threat model before deployment. References: OWASP authentication and OWASP authorization.