Authentication, Authorization, and Context

Stable

Applies to: Hub Workspace, Intake account portal, and future client surfaces

Updated: July 2026

These three layers are intentionally separate. Mixing them creates insecure or confusing products.

The three layers

Authentication
      ↓
Authorization
      ↓
Customer Context

Layer	Question	Owner
Authentication	Who is this WordPress user?	WordPress (credentials, cookies, sessions)
Authorization	What may they access in this product?	Product (caps, memberships, policies)
Customer Context	Which Workspace / account / site do they enter?	Product (server-resolved; fail closed)

End-to-end flow

User
  ↓
WordPress Authentication (wp_signon / cookies)
  ↓
Product Authorization (capabilities + memberships)
  ↓
Workspace Context (account + site)
  ↓
Workspace Shell
  ↓
Cards

Hub authorization chain

User
  ↓
Tenant / Account membership
  ↓
Site (site.account_id)
  ↓
Permission (e.g. vexal_hub_access + membership role)
  ↓
Workspace

A valid WordPress login is necessary but never sufficient for Hub Workspace.

Product surfaces

Intake: /vexal-intake/account/ — Authentication Experience reference (1.0.027–1.0.028)
Hub: /vexal-login/ → /vexal-workspace/ — same experience pattern, Hub authorization

Operators and administrators

Operators keep WordPress / Operator Console paths. Operator capability does not create customer Workspace context. Explicit operator preview is separate.