Access control & tenant isolation

This page describes how VWAM authenticates users, how it enforces permissions, and how it keeps each organization's data separate.

Authentication

The platform API requires signed, expiring bearer tokens. At sign-in, a user receives an access token and a refresh token. The access token carries the user's identity, organization, and permission set, and it expires after 8 hours. The refresh token has a longer life, and the client uses it to obtain new access tokens. A user signs in with an email address and a password, or with Google sign-in. VWAM stores a password only as a bcrypt hash.

Role-based access control

VWAM implements role-based access control (RBAC). A user's membership in an organization carries a role. Each role maps to fine-grained resource-and-action permissions, for example the permission to publish a chat configuration. API endpoints enforce those permissions. VWAM can also layer individual permission overrides on top of a user's role.

Per-organization isolation

VWAM is multi-tenant. Every record that belongs to a merchant carries an organization identifier. API queries are scoped to the organization of the authenticated caller. One organization's users therefore cannot read or act on another organization's data.

The application layer enforces this isolation, through organization-scoped queries and access checks on every request. VWAM does not depend on a single database mechanism alone. If your review needs the specifics for each data path, contact us for a direct walkthrough.

Audit

VWAM captures configuration changes to a chat as version history. VWAM also records per-user sign-in activity. We are expanding our audit capabilities as part of our security program. If your review requires specific audit or access-log guarantees, contact us to discuss the options for your deployment.