Concepts & Architecture
Before integrating, it helps to understand how Vyntech Account is structured. This page explains the core entities and how they relate to each other.
System Overview
┌─────────────────────────────────────────────────────────────┐ │ VYNTECH ACCOUNT │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Tenant A │ │ Tenant B │ │ Tenant C │ │ │ │ │ │ │ │ │ │ │ │ Users │ │ Users │ │ Users │ │ │ │ Roles │ │ Roles │ │ Roles │ │ │ │ Sessions │ │ Sessions │ │ Sessions │ │ │ │ Policies │ │ Policies │ │ Policies │ │ │ │ Settings │ │ Settings │ │ Settings │ │ │ │ API Keys │ │ API Keys │ │ API Keys │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ ├─────────────────────────────────────────────────────────────┤ │ Shared Infrastructure │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ Risk │ │ Audit │ │ Email │ │ Webhooks │ │ │ │ Engine │ │ Logs │ │ Service │ │ Dispatcher │ │ │ └──────────┘ └──────────┘ └──────────┘ └──────────────┘ │ └─────────────────────────────────────────────────────────────┘
Tenants
A tenant represents an organization — your customer, a business unit, or your own company. Every resource in the system is scoped to a tenant. Tenants are completely isolated from each other.
idUUID — unique identifierslugURL-safe name (e.g., acme-corp) — must be uniqueplanfree, pro, or enterprise — determines quotas and featuressettingsJSONB — tenant-specific security, access, branding, and behavior configurationstatusactive or suspendedMulti-tenancy model: A single Vyntech Account instance serves many tenants. Data is isolated at the database level (tenant_id foreign key on every table). Cross-tenant access is only possible for platform administrators with the platform scope.
Users
A user belongs to exactly one tenant. Users authenticate with email + password, optionally with MFA (TOTP). Each user has a profile, verification status, and zero or more assigned roles.
emailUnique within the tenant (case-insensitive)email_verifiedWhether the user has confirmed their emailmfa_enabledWhether TOTP MFA is activestatusactive, suspended, or pendingpassword_hashArgon2id hashed — never exposed via APIdisplay_nameHuman-readable nameSessions
Every successful login creates a session. Sessions track the device (user-agent), network (IP address), and activity (last_active_at). They're stored in both PostgreSQL and Redis for fast lookup.
- •Limits: Configurable max sessions per user. When exceeded, the oldest session is auto-revoked.
- •Timeout: Configurable inactivity timeout. 0 = no timeout (uses refresh token lifetime).
- •Revocation: Sessions can be revoked individually or all-at-once by admins.
- •Anomaly detection: The risk engine monitors for unusual patterns (UA change on same IP, IP hopping mid-session).
Tokens
Vyntech Account issues two types of JWT tokens, both signed with Ed25519 (EdDSA):
Access Token
Short-lived (15min default). Contains user ID, tenant ID, email, roles, permissions, and session ID. Used for API authorization.
Refresh Token
Long-lived (7 days default). Used solely to obtain new access tokens. Rotated on each use (old one blacklisted). Tied to a session.
Token verification: Your backend validates tokens by checking the EdDSA signature against the public key from /.well-known/jwks.json. No network call to Vyntech needed — verification is offline and fast.
Roles & Permissions
RBAC (Role-Based Access Control) is the primary authorization model. Each tenant has system roles (owner, admin, member, viewer) and can create custom roles.
- •Roles are scoped to a tenant. They contain a set of permissions.
- •Permissions are resource:action pairs (e.g.,
users:read,roles:assign). - •User-role assignments can be scoped (tenant-level or platform-level) and can have expiration dates.
Permissions are included in the access token claims, so your backend can check authorization without additional API calls.
Cedar Authorization Policies
For fine-grained access control beyond RBAC, Vyntech Account uses Cedar — a policy language developed by AWS. Cedar policies evaluate permit/forbid decisions based on principal, action, resource, and context.
// Allow owners to manage all resources in their tenant
permit (
principal in Role::"owner",
action,
resource
) when {
resource.tenant == principal.tenant
};
// Forbid suspended users from any action
forbid (
principal,
action,
resource
) when {
principal.status == "suspended"
};Policies are evaluated via the POST /api/v1/authz/check endpoint or embedded in your backend using the Cedar evaluation library.
Tenant Settings
Every tenant has a settings object (stored as JSONB) that controls behavior across 6 categories:
🛡️ Security
Password policy, MFA enforcement, session limits, lockout rules
🎨 Branding
Logo, colors, favicon, custom CSS, support URLs
🔑 Access Control
Auth methods, IP lists, email domains, self-registration
🔔 Notifications
Email alerts, webhook URL, subscribed events
📊 Limits & Quotas
Max users, roles, API keys, policies, rate limits
🧠 Behavior Engine
Risk thresholds, impossible travel, device challenges
Settings are merged (not replaced) on save, cached in Redis for 5 minutes, and enforced on every auth operation. See the Tenant Settings guide for details.
Risk Engine
Every login is evaluated by the behavioral risk engine. It computes a score (0–100) based on multiple signals and compares it against the tenant's configured thresholds.
| Signal | Weight | Description |
|---|---|---|
| new_device | +20 | User-agent never seen before for this user |
| new_ip | +15 | IP address not in user's recent history |
| new_country | +25 | GeoIP country never seen for this user |
| impossible_travel | +35 | Different country within short time window |
| login_velocity | +20 | High attempt rate from same IP |
| credential_stuffing | +30 | Same IP targeting many different accounts |
| tor_exit_node | +40 | IP is a known Tor exit relay |
| vpn_proxy | +15 | IP belongs to a known VPN/proxy service |
| session_anomaly | +25 | UA changed on same IP within active session |
0–69
ALLOW
70–89
CHALLENGE (step-up MFA)
90–100
BLOCK
Audit Logs
Every action is recorded in an immutable audit trail: logins, failed attempts, role changes, policy updates, session revocations, settings modifications. Each entry includes the actor, IP address, timestamp, resource, and status. Retention is configurable per tenant (plan-dependent defaults: 7 days free, 90 days pro, 1 year enterprise).
Plans & Quotas
Each tenant is on a plan that determines default limits, available features, and configurable settings. Limits can be overridden per-tenant via the admin panel. All plans include the core identity engine and audit logging.
| Feature | Free | Pro | Enterprise |
|---|---|---|---|
| Monthly Price | $0 | $29 | Custom |
| Users & Authentication | |||
| Monthly Active Users | 1,000 | 1,000,000 | Unlimited |
| Password + TOTP MFA | ✓ | ✓ | ✓ |
| WebAuthn / Passkeys | — | ✓ | ✓ |
| SSO (SAML 2.0 / OIDC) | — | — | ✓ |
| Email Verification + Password Reset | ✓ | ✓ | ✓ |
| Authorization | |||
| System Roles | ✓ | ✓ | ✓ |
| Custom Roles | — | 10 | Unlimited |
| Cedar Policies | — | 20 | Unlimited |
| API Keys | — | 5 | Unlimited |
| Sessions & Limits | |||
| Max Sessions Per User | 3 | 10 | Unlimited |
| Rate Limiting | 60/min | 300/min | Custom |
| Audit Retention | 7 days | 90 days | 1 year |
| Configurable Settings | |||
| Password Policy | ✓ | ✓ | ✓ |
| MFA Enforcement | ✓ | ✓ | ✓ |
| Account Lockout Config | ✓ | ✓ | ✓ |
| Email Domain Restriction | — | ✓ | ✓ |
| IP Allowlist / Blocklist | — | ✓ | ✓ |
| Custom Branding | — | ✓ | ✓ |
| Webhooks | — | ✓ | ✓ |
| Email Alerts | — | ✓ | ✓ |
| Behavior & Risk Engine | |||
| New Device / New IP Detection | ✓ | ✓ | ✓ |
| GeoIP + Impossible Travel | — | ✓ | ✓ |
| Credential Stuffing Detection | — | ✓ | ✓ |
| Session Anomaly Detection | — | — | ✓ |
| Tor / VPN Blocking | — | — | ✓ |
| Custom Risk Thresholds + Actions | — | — | ✓ |
| Admin Alerts on Risk Events | — | — | ✓ |
| Support & Compliance | |||
| Support | Community | Priority + SLA | |
| SOC 2 / ISO 27001 Reports | — | — | ✓ |
| On-Premise Deployment | — | — | ✓ |