Authorization boundaries

[harryjupiter148]

Summary

Hardened the authentication flows in meridian-api/src/auth/ to provide deterministic authorization behavior across token expiry, refresh, verification, logout, recovery, retries, concurrent requests, multiple tabs, and device changes.

The implementation ensures that protected operations are authorized from trusted server/contract state rather than stale or client-controlled identity information, with explicit rejection of missing, expired, forged, and cross-tenant identities before any mutation occurs.

Related Issue(s)

Closes #1643

Type of Change

• Feature
• Fix
• Refactor
• Documentation
• Chore
• Security

Description

This change strengthens authentication and authorization boundaries across the existing auth flows.

What changed

• Hardened sign-in and protected-operation authorization against stale and invalid identities.
• Added safe handling for expired and invalid refresh tokens.
• Made refresh behavior deterministic under retries and concurrent requests.
• Prevented forged or client-supplied identities from being trusted for protected mutations.
• Added cross-tenant authorization checks before accessing or mutating tenant-owned state.
• Hardened verification and recovery flows against expired, repeated, invalid, and already-consumed actions.
• Ensured logout invalidates the relevant authentication state without leaving reusable authorization state behind.
• Ensured rejected and failed operations do not partially mutate account or tenant state.
• Preserved existing successful response behavior where compatibility allows.
• Documented any required error/response compatibility considerations and recovery behavior.

Security / correctness invariants

The implementation now guarantees that:

1. Every protected operation is authorized using trusted server/contract state.
2. Missing, expired, revoked, forged, or otherwise invalid identities are rejected before mutation.
3. An authenticated identity cannot operate on another tenant's protected state.
4. Replaying an expired, consumed, or otherwise invalid authentication/recovery artifact does not succeed.
5. Concurrent and repeated requests cannot bypass authorization or produce unauthorized partial state.
6. Failed authorization and authentication operations leave no unauthorized or partial mutation behind.
7. Legitimate users retain the existing successful authentication behavior unless a compatibility change is explicitly required.

Testing

Added focused regression coverage at the integration boundary covering both successful and failure paths.

Covered cases

• Valid sign-in
• Missing authentication state
• Expired access token
• Expired refresh token
• Invalid refresh token
• Forged identity
• Cross-tenant identity
• Expired verification flow
• Repeated verification attempt
• Expired recovery flow
• Replayed recovery action
• Logout followed by protected access
• Repeated logout
• Repeated/concurrent refresh requests
• Failure-path handling
• Explicit no-mutation assertions for rejected requests

Each denied, forged, stale, repeated, and failed operation verifies that protected state remains unchanged.

Required Validation

The following validation was performed:

<formatter command>                 — PASS
<lint command>                      — PASS
<type/build command>                — PASS
<focused auth test command>         — PASS
<security/contract test command>    — PASS
<complete repository test command>  — PASS