Use Cases & Decision Guide
Vyntech Account is powerful, but it's not the right tool for every situation. This page helps you decide whether it fits your project, shows real-world use cases where it shines, and honestly describes scenarios where you might want a different approach.
Use Cases
Each use case below describes a real scenario, the specific Vyntech Account features that solve it, and how the pieces fit together.
Multi-Tenant SaaS Platform
You're building a B2B product where each customer organization needs their own isolated user base, roles, and security configuration. Without native multi-tenancy, you'd build tenant scoping into every query, every permission check, and every session store — error-prone and expensive to maintain.
Features Used
- •Tenant isolation — each org gets a tenant with its own users, roles, and settings
- •Per-tenant password policies — one customer requires 12-char passwords, another accepts 8
- •Per-tenant MFA enforcement — enterprise customers mandate TOTP, free-tier customers don't
- •Tenant-scoped roles — 'admin' in Acme Corp has no access to Beta Inc's data
- •API keys scoped per tenant — customers generate keys that only access their own resources
How It Works
1. You call POST /tenants to create "acme-corp" with plan=pro 2. Users register under tenant_id=acme-corp 3. Each JWT contains tid="tnt_acme..." — your backend scopes all queries by tid 4. Acme's admin configures their own password policy and MFA rules via settings API 5. No code changes needed when Acme changes their security requirements
Compliance-Ready Application
Your product handles sensitive data (healthcare, finance, legal) and you need to demonstrate access controls, session management, and anomaly detection to pass audits. Building this from scratch typically takes 3-6 months and requires ongoing maintenance.
Features Used
- •Audit logs — every authentication event, role change, and session action is recorded with context
- •Session controls — configurable idle timeout, absolute timeout, and max concurrent sessions
- •Risk engine — flags impossible travel, new devices, and velocity anomalies automatically
- •Webhook notifications — alert your security team when high-risk events occur
- •IP access control — restrict login to approved IP ranges per tenant
Compliance Mapping
SOC 2 CC6.1Role-based access control with least privilegeSOC 2 CC6.2User provisioning and de-provisioning via APISOC 2 CC7.2Anomaly detection via behavioral risk engineISO 27001 A.9Password policies, session limits, MFAStartup Shipping an MVP
Your team is small and your runway is limited. You need real authentication — not a prototype you'll rewrite in 6 months — but you can't spend 4 weeks building auth flows. You need to go from zero to production auth in a day.
What You Get on Day One
- •Registration with email verification and password policy enforcement
- •Login with automatic risk scoring (no configuration needed)
- •Token refresh with rotation and reuse detection
- •Password reset flow with email delivery
- •EdDSA-signed JWTs you can validate without calling our API
- •OIDC discovery so standard libraries auto-configure
Integration Timeline
Complex Permission Models (RBAC + ABAC)
Your app has multiple user types with different access levels, and simple role checks aren't enough. You need fine-grained permissions and potentially attribute-based policies (e.g., "editors can publish only in their own department").
Features Used
- •Roles with permission sets — define 'editor' as [posts:read, posts:write, media:upload]
- •Multiple roles per user — a user can be both 'editor' and 'billing-viewer'
- •Permissions in JWT claims — check access in your backend without extra API calls
- •Cedar policies — write attribute-based rules like 'allow if resource.department == user.department'
- •Authorization check endpoint — POST /authz/check for complex decisions your backend can't resolve locally
Example Permission Structure
Role: "editor"
Permissions: [posts:read, posts:write, posts:publish, media:upload]
Role: "viewer"
Permissions: [posts:read, media:read]
Role: "admin"
Permissions: [posts:*, media:*, users:read, users:write, roles:manage]
User: jane@acme.com
Roles: [editor, billing-viewer]
Effective permissions: [posts:read, posts:write, posts:publish,
media:upload, billing:read]High-Security Financial Application
Your app handles money or sensitive personal data. You need defense-in-depth: adaptive MFA, login anomaly detection, device trust, and the ability to block suspicious access in real time — without building a dedicated security engineering team.
Features Used
- •Risk engine — scores every login based on device, location, velocity, and behavioral patterns
- •Adaptive challenges — low risk = pass through, medium = email OTP, high = block + alert
- •Device fingerprinting — recognizes returning devices and flags new ones
- •Impossible travel detection — flags login from Sydney 10 minutes after a login from London
- •IP allowlists — restrict access to known corporate IPs for enterprise tenants
- •Session invalidation — revoke all sessions instantly on password change or security event
Risk Engine Decision Flow
Login attempt from user │ ├── Known device + known IP + normal time → Score: 5 → Allow ├── New device + known IP → Score: 35 → Allow (flag) ├── Known device + new country → Score: 55 → Email OTP challenge ├── New device + new country → Score: 75 → Email OTP challenge └── Impossible travel detected → Score: 95 → Block + admin alert
Developer Platform with API Access
You're building a platform where customers interact via both a dashboard (browser) and programmatic API access (scripts, CI/CD, SDKs). You need human auth and machine auth to coexist under the same permission model.
Features Used
- •API keys — tenant-scoped keys for programmatic access with defined permissions
- •OAuth 2.1 — authorization code flow for third-party integrations
- •JWT-based sessions — for dashboard users with refresh token rotation
- •Shared RBAC — same roles and permissions apply whether access is via UI or API key
- •Webhook notifications — notify your system when new API keys are created or revoked
Access Patterns
Human (browser): Login → JWT (access + refresh) → Dashboard API calls Machine (script/CI): API Key → Authorization: Bearer vyn_key_... → API calls Third-party integration: OAuth 2.1 code flow → Access token with limited scopes → API calls All three paths → same permission model → same resource access rules
When Not to Use Vyntech Account
We believe in honest tooling. Below are scenarios where Vyntech Account adds unnecessary complexity or simply doesn't fit the constraints. For each, we explain why and suggest alternatives.
Single-user personal projects
A full identity platform (tenants, roles, sessions, risk scoring) adds operational overhead when your app has one user: you. The complexity doesn't pay off.
A session cookie, HTTP Basic Auth, or next-auth with a credentials provider. If you outgrow it later, migrate then.
Consumer social apps at massive scale (millions of users, low security needs)
Vyntech Account is optimized for B2B multi-tenancy with strong security. If your users just tap 'Sign in with Google' and never configure anything, simpler providers are more cost-effective at consumer scale.
Firebase Auth, Supabase Auth, or Clerk — purpose-built for consumer social login with generous free tiers.
Fully offline or air-gapped environments
Vyntech Account is a cloud-hosted service. Your application must be able to reach id.vyntech.com.au at runtime for login, token refresh, and user management. No offline fallback exists.
Certificate-based mutual TLS, local credential stores, or self-hosted identity (Keycloak, Ory Kratos) deployed within the air-gapped network.
You require full source code ownership
Some compliance frameworks or enterprise architectures mandate that identity infrastructure is self-operated with auditable source code. A managed external service won't satisfy this requirement regardless of its capabilities.
Self-hosted Keycloak (Java), Ory Kratos (Go), or a custom solution built on established cryptographic libraries. Accept the ongoing maintenance cost.
Non-standard authentication protocols
Vyntech Account implements OAuth 2.1, OIDC, and TOTP MFA. If you need custom biometric verification, hardware tokens beyond TOTP (pre-WebAuthn support), or proprietary SSO protocols, our API won't support the full flow.
Build the custom auth mechanism yourself. You can still use Vyntech Account for user management, sessions, and roles while handling the non-standard authentication externally.
Static sites with no server-side logic
If your entire application is static HTML/CSS/JS with no backend, and you just need a password gate on a page, integrating a full IAM platform is disproportionate to the problem.
CDN-level password protection (Cloudflare Access, Netlify password protection) or a simple .htaccess rule.
Quick Decision Matrix
Use this table to quickly assess if Vyntech Account fits your project.
| Requirement | Fit | Notes |
|---|---|---|
| Multi-tenant user isolation | ✓ Perfect | Core design principle — zero extra work |
| RBAC with custom roles | ✓ Perfect | Built-in roles and permissions per tenant |
| Risk-based adaptive auth | ✓ Perfect | Behavioral risk engine included |
| MFA (TOTP) | ✓ Perfect | Configurable per-tenant enforcement |
| OAuth 2.1 / OIDC provider | ✓ Perfect | Full spec implementation with PKCE |
| Audit logging | ✓ Perfect | Every auth event is logged with context |
| Social login (Google, GitHub, etc.) | ~ Partial | Supported via OIDC federation — not all providers pre-configured |
| Passwordless / Magic Links | ~ Partial | Email OTP via risk challenge; dedicated magic link flow on roadmap |
| Hardware security keys (WebAuthn) | ◌ Roadmap | FIDO2/WebAuthn support planned for Q3 2027 |
| Self-hosted / on-premise | ✗ No | Cloud-hosted only — no self-hosted option |
| Millions of free-tier users | ~ Partial | Designed for B2B scale; consumer-scale pricing may not compete |
| Custom auth protocols | ✗ No | Standard OAuth 2.1 / OIDC only |
How It Compares
A high-level comparison to help you understand where Vyntech Account sits relative to other identity solutions.
| Feature | Vyntech Account | Auth0 | Firebase Auth | Keycloak |
|---|---|---|---|---|
| Multi-tenancy (native) | ✓ | ✓ (Organizations) | ✗ | ✓ (Realms) |
| Behavioral risk engine | ✓ | ✓ (Enterprise) | ✗ | ✗ |
| Cedar policy engine | ✓ | ✗ | ✗ | ✗ |
| Per-tenant settings | ✓ | Partial | ✗ | ✓ |
| Self-hosted option | ✗ | ✗ | ✗ | ✓ |
| OIDC / OAuth 2.1 | ✓ | ✓ | Partial | ✓ |
| EdDSA tokens | ✓ | ✗ (RS256) | ✗ | ✗ |
| Webhook notifications | ✓ | ✓ | ✓ (Functions) | ✓ (Events) |
| GraphQL + gRPC APIs | ✓ | ✗ | ✗ | ✗ |
| Free tier | ✓ | ✓ | ✓ | ✓ (OSS) |
Our sweet spot: Vyntech Account is purpose-built for multi-tenant B2B applications that need strong security defaults, fine-grained RBAC, and a behavioral risk engine — without the enterprise pricing of Auth0 or the operational burden of Keycloak.
Real-World Architecture Patterns
Here's how teams typically integrate Vyntech Account into their stack.
Pattern A: SaaS with Shared Frontend
A single Next.js frontend serves all tenants. Tenant context is determined by subdomain or slug in the URL. Vyntech Account handles all auth; your backend validates JWTs and scopes data by tid.
User → app.yourproduct.com/acme-corp → Frontend sends login to id.vyntech.com.au → Receives JWT with tid=tnt_acme → Frontend sends API requests with Authorization: Bearer <jwt> → Your backend validates JWT, extracts tid, scopes queries
Pattern B: Microservices with Shared Identity
Multiple backend services share the same identity layer. Each service validates tokens independently using the JWKS endpoint. No service-to-service auth coordination needed.
┌─── Orders Service (validates JWT)
User → API Gateway ─┼─── Billing Service (validates JWT)
└─── Notifications Service (validates JWT)
│
└── All services fetch JWKS from
id.vyntech.com.au/.well-known/jwks.jsonPattern C: White-Label Platform
Each tenant gets a custom-branded login experience. The public branding endpoint serves tenant-specific logos, colors, and copy. Your frontend fetches branding and renders accordingly.
User → login.acme-corp.com (your whitelabel domain) → Frontend calls GET /public/branding/acme-corp → Renders login form with Acme Corp's logo & colors → Auth goes through id.vyntech.com.au with tenant_id=acme-corp → User sees Acme Corp branding throughout
Making the Decision
Ask yourself these questions. If you answer "yes" to 3 or more, Vyntech Account is likely a strong fit.
Do I need multiple organizations/tenants with isolated user bases?
Do I need role-based or attribute-based access control?
Do I want MFA, risk scoring, or adaptive security without building it myself?
Am I building a product that will eventually need SOC 2 or similar compliance?
Do I want REST + GraphQL + gRPC access to my identity data?
Do I need per-tenant configuration (password policies, session limits, branding)?
Am I building a B2B SaaS where my customers expect enterprise-grade security?
Do I want webhook notifications for security events?
Still unsure? Start with the Quickstart Guide — you can have a working integration in under 5 minutes with the free tier. There's no commitment, and you'll know quickly whether it fits your mental model.
What's Next
Quickstart Guide →
Get from zero to authenticated users in 5 minutes
Concepts & Architecture →
Understand tenants, users, sessions, roles, and how they connect
Authentication Flows →
Visual diagrams of every auth flow (login, MFA, risk challenge)
Authentication API →
Full endpoint reference for login, register, token refresh, and more