Skip to main content

Authentication Service

SalesArck authentication is implemented as:

  • Supabase for OTP identity and JWT issuance,
  • SalesArck API middleware for role/status/tenant authorization.

Login Flow​

Two Auth Middleware Modes​

Profile mode (authProfileMiddleware)​

Used only by GET /api/v1/auth/me.

Purpose:

  • return session profile even when app use should be blocked,
  • allow frontend to render pending/suspended/blocked states.

Returns status, canUseApp, optional code, and needsMerchantOnboarding.

Strict mode (authMiddleware)​

Used by protected route groups.

Requirements:

  • valid bearer token,
  • admin role must use approved email domain (@doshidhruv.com),
  • user status must be active.

On success, attaches auth context:

{
  userId: string,
  role: UserRole,
  tenantIds: string[]
}

Role and Status Assignment​

First-login derivation in resolveOrCreateUserRow:

  • requested_role=client|merchant -> role client, status pending_approval
  • requested_role=admin + approved domain -> role admin, status active
  • fallback -> role consumer, status active

Existing rows are not overwritten by later metadata values.

Account-State Gating​

Supported states:

  • active
  • pending_approval
  • suspended

Frontend route handling uses profile response flags:

  • pending approval -> /pending-approval
  • suspended or admin-domain violation -> /account-blocked
  • merchant onboarding incomplete -> /onboarding

Security Properties​

  1. JWT verification occurs server-side using Supabase service-role client.
  2. Role and tenant memberships are read from SalesArck tables, not trusted from browser.
  3. Admin role is constrained by email domain check.
  4. Protected routes require strict middleware, independent of UI route guards.
Last updated on
Written byDhruv Doshi