Developer documentation
Authentication Guide
QVTM authentication is not password replacement by copying password semantics into a new API. It is a trust workflow based on customer/domain context, operator authority, device state, short-lived challenges, and verifier evidence.
Main actors
| Actor | Role |
|---|---|
| Customer | Commercial/account boundary that owns domains, users, applications, and integrations |
| Domain | Operational boundary for QVTM policy, devices, operators, and applications |
| Operator | Human or service authority that approves or operates QVTM flows |
| User | End-user identity associated with customer applications |
| Developer | Integration user granted RBAC-scoped access in the SaaS Admin Console |
| Device | Cryptographic endpoint participating in approvals and trust evidence |
| Verifier | Service that checks signed evidence and state before allowing access |
Token boundary
Provisioning tokens are backend-only credentials. They are issued through QVTM operational workflows and must never be embedded in browsers, mobile applications, static sites, or customer-controlled clients.
Use provisioning tokens to create or configure customer/domain resources from a trusted backend. Use short-lived challenge and invite material for user-facing approval flows.
Login lifecycle
- Backend creates or resolves customer/domain context.
- Backend creates an operator, user, or application context as needed.
- Backend requests a login or approval challenge.
- Operator device scans or receives the challenge.
- Device approves using the QVTM mobile/control-plane flow.
- Application checks challenge status and verifier evidence.
- Application grants a local session only after QVTM trust state is valid.
Fail-closed rules
- Missing verifier evidence means no access.
- Expired challenge means no access.
- Unknown device state means no access.
- Customer/domain mismatch means no access.
- A browser-visible provisioning token is a security incident.