Authorization for SaaS teams whose permissions
stopped being simple.

Add tenant-aware roles, feature actions, per-user overrides, and API-based permission checks without turning your codebase into scattered if-statements.

Built for B2B SaaS teams adding RBAC, tenant permissions, and customer-specific access rules.

Authorization as a Service. Without scattered permission logic.

Start in staging

Staging beta: create a test account and protect one non-critical permission flow first.

Authorization breaks quietly. Until it doesn't.

Most SaaS teams start with simple role checks. Then customers ask for tenant-specific permissions, exceptions, auditability, and rules that no longer fit cleanly in app code.

The start

if user.role == "admin"
A few feature flags
One customer, one rule
Permission checks hidden in handlers

Then reality hits

Tenant-specific permissions
Per-user exceptions
Enterprise access requests
No clear reason why access was allowed

The hidden cost

Developers add conditionals
Permissions become hard to test
Support cannot explain access issues
Security reviews become stressful

One check before the action.

Keep authorization decisions out of scattered application code. Call Thauth before the protected action runs.

A check is one authorization decision, for example: "Can user_123 refund an invoice in tenant_acme?"

Example result

{
  "allowed": false,
  "reason": "default_deny"
}

TypeScript /v1/check

const decision = await thauth.check({
  subject: "user_123",
  tenant: "acme",
  feature: "billing",
  action: "refund"
})

if (!decision.allowed) {
  throw new ForbiddenError(decision.reason)
}

A simple, explicit authorization model.

Model permissions the way your SaaS actually works: tenants, features, actions, roles, subjects, and overrides.

Tenant

|- Features → Actions // billing -> refund

|- Roles → Permissions // finance_admin = billing:refund

|- Subjects → Role assignments // user_123 in tenant_acme

\- Overrides → Explicit allow/deny exceptions // deny billing:refund

Every decision is explainable: who asked, in which tenant, for which feature/action, and why it was allowed or denied. Read the authorization model docs.

Explicit deny

Deny overrides win first, so critical restrictions cannot be accidentally bypassed.

Explicit allow

Allow overrides handle special cases without creating one-off roles for every exception.

Role permission

Normal access comes from roles assigned to subjects within a project and tenant context.

Default deny

If nothing matches, access is denied.

No policy language required. No graph model required. No infra team required.

For teams stuck between hardcoded RBAC and heavyweight policy engines.

Thauth sits between "just add another role check" and adopting a full policy-engine platform before your team is ready. Review the API overview.

Too simple

Roles hardcoded in app code
Permissions scattered across handlers
Customer exceptions become patches
Nobody owns the permission model

Best fit for growing SaaS

Thauth.dev

Tenant-aware roles
Feature/action permissions
Per-user allow/deny overrides
API checks with decision reasons
Project-scoped API keys
Check logs for visibility

Too complex

Policy languages slow the team down
Graph models are overkill early on
Infra burden exceeds the problem
Harder to explain to product/support teams

Define. Assign. Check.

Define your model in the dashboard, assign access rules, then call Thauth before protected actions.

Define features and actions

Describe what your app protects, then attach actions to it. Examples: billing:refund, reports:view, secrets:read.

Assign roles and overrides

Give subjects roles per tenant, then add explicit allow/deny exceptions when needed.

Check access from your app

Call the API or SDK before the protected action runs. Thauth returns allow/deny with a reason.

The core flow is implemented: dashboard configuration, API keys, runtime checks, check logs, SDKs, and staging deployment.

Check endpoint docs API overview Public endpoints

Pricing based on authorization checks, not seats.

Start free, then grow based on the number of authorization decisions your apps make.

Checks / month 100k

Scale 1 project • 1 teammate

Staging experiments
Prototypes
Local testing
Core roles, subjects, and decision API

Start with Free

Best for trying the model before production rollout.

Recommended

Checks / month 1M

Scale Unlimited projects • 5 teammates

First staging integration
Small production apps
Overrides and batch checks
Basic check logs

Start with Starter

Recommended for most SaaS teams moving from hardcoded checks.

Checks / month 10M

Scale Unlimited projects • 15 teammates

Production workloads
Multiple tenants
Higher throughput
30-day audit retention

Choose Growth

Built for teams whose authorization layer is already on the customer path.

Checks / month 50M

Scale Unlimited projects • Unlimited teammates

Higher check volume
Advanced limits and log retention
90-day audit retention
Priority support

Choose Scale

For platforms where authorization is part of the core request path at high volume.

Usage model

What counts as a check

A check is one authorization decision, for example: "Can user_123 perform action X in tenant Y?"

Monthly plans include a check volume
Batch requests count each decision inside the batch
Usage warnings appear at 80%, 100%, and 120%
Usage is tracked so you can understand authorization load before upgrading

Usage resets monthly. Checks above your plan are tracked for upgrade planning. See how authorization checks work.

Enterprise

Custom contract

For custom contracts, dedicated support, security/legal review, and higher limits.

Checks / month 100M+

Rollout Custom limits • Dedicated support

Custom limits
Dedicated support path
Security/legal review
Higher limits

Talk to us about Enterprise

Tell us your expected volume and compliance constraints and we will scope the rollout with you.

Prefer email? Talk to us directly.

Designed so authorization stays inspectable.

Authorization infrastructure needs more than a clean API. It needs safe defaults, visible decisions, and clear operational boundaries.

Dashboard safety

The dashboard is server-rendered through a BFF. Browser sessions do not directly call internal admin APIs, and backend admin tokens are not exposed in the network tab.

Read security docs

Backend-enforced ownership

Account and project ownership are enforced by backend middleware. Cross-account access attempts are rejected with 403 and monitored.

Review boundaries

Clear decision behavior

Deny overrides win first, unmatched requests default to deny, and check logs help explain authorization outcomes.

Review model

Operational visibility

Request logs, failed authorization attempts, 403 ownership failures, and runtime behavior are monitored through the observability stack.

Read security docs

Legal readiness

Terms, privacy, acceptable use, DPA, and security documentation are prepared for SaaS buyers.

Review legal docs

Simple beta infrastructure

Thauth currently runs on an intentionally simple VPS deployment with Docker Compose, Traefik, Cloudflare DNS, daily backups, and vertical scaling first.

Review operations

Try Thauth where permission bugs hurt least first: staging.

Add Thauth to one non-critical permission flow, validate the model, then decide what deserves production traffic.

Go to signup

Read the docs

Use a test account before moving production traffic.

Check endpoint

Authorization for SaaS teams whose permissions
stopped being simple.

Authorization breaks quietly. Until it doesn't.

The start

Then reality hits

The hidden cost

One check before the action.

A simple, explicit authorization model.

Explicit deny

Explicit allow

Role permission

Default deny

For teams stuck between hardcoded RBAC and heavyweight policy engines.

Too simple

Thauth.dev

Too complex

Define. Assign. Check.

Define features and actions

Assign roles and overrides

Check access from your app

Pricing based on authorization checks, not seats.

$0 /month

$49 /month

$149 /month

$399 /month

What counts as a check

Custom contract

Designed so authorization stays inspectable.

Dashboard safety

Backend-enforced ownership

Clear decision behavior

Operational visibility

Legal readiness

Simple beta infrastructure

Try Thauth where permission bugs hurt least first: staging.

Authorization for SaaS teams whose permissionsstopped being simple.

Authorization breaks quietly. Until it doesn't.

The start

Then reality hits

The hidden cost

One check before the action.

A simple, explicit authorization model.

Explicit deny

Explicit allow

Role permission

Default deny

For teams stuck between hardcoded RBAC and heavyweight policy engines.

Too simple

Thauth.dev

Too complex

Define. Assign. Check.

Define features and actions

Assign roles and overrides

Check access from your app

Pricing based on authorization checks, not seats.

$0 /month

$49 /month

$149 /month

$399 /month

What counts as a check

Custom contract

Designed so authorization stays inspectable.

Dashboard safety

Backend-enforced ownership

Clear decision behavior

Operational visibility

Legal readiness

Simple beta infrastructure

Try Thauth where permission bugs hurt least first: staging.

Authorization for SaaS teams whose permissions
stopped being simple.