Identity Infrastructure for SaaS

Stop rebuilding auth featuresand build your product

Everything your SaaS needs to manage identity, access and user lifecycle.

Identity configurationstagingproduction

Succeeded1.13sDeploymentn5s6mmy3b7ns4cmrh9aeen8h

authentication.mfa.totp: required
authentication.providers: 3 to 5 enabled
protection.bot: turnstile
tokens.claims.plan: preview to live
communications.templates: unchanged

Multi-factor, sign-in providers, bot protection, token claims and delivery templates are settings here, not five integrations to keep in sync

Authentication

Everything behind a sign-in

Verification, sessions, roles and recovery ship as one system, inspectable down to a single request

Sign-in methods

Email, phone, username or social sign-in, with a password or a one-time code

[email protected]password

+351 912 •••• 88sms otp

ada.lovelaceusername

···social

one identity

Multi-factor

A second factor by app or SMS, plus recovery codes for the day someone loses the phone

471

totpon
recovery8 of 10
smsoff

Sessions and devices

See every device someone is signed in on and cut any one of them off, without touching the others

macOS · ChromeLisboncurrent

iOS · SafariPorto

Windows · EdgeMadridrevoked

Roles and permissions

The same role can mean different things per customer, so you stop writing a permission layer per tenant

owner

projects:writeinvoices:readmembers:invite

Token claims

Put the role, tenant or plan into the access token, and preview it against a real user before it ships

claims.json

"email": "{{ user.email }}",
"role": "{{ grants.0.role }}",
"tenant": "{{ org.slug }}",
"plan": "{{ billing.plan }}",

Sudo mode

One more confirmation before a destructive action — for that action only, never the whole session

Sensitive actions

single use · 5m

Abuse protection

Rate limits and a bot check in front of sign-in, recovery and lookups — the endpoints that get hammered first

8 blocked · bot checks

When your users are active

Sign-ins, sign-ups and verifications on one clock, so you can see when your users actually show up

montuewedthufrisatsun

weekday peak 10:00 · 1,284 events

Every one of these is a setting, not a release — configured per environment and promoted with a diff

What one request actually touches

Six requests a product makes, and the systems each one wakes up on the way through

Verify

eyJhbGciOiJFZ

protectionRate limit checked
1ms
tokensSignature verified
2ms
authorizationRole matched · owner
5ms
authorizationScope granted · projects:write
3ms
——
0ms
——
0ms

Verified for proj_16tbwq3411ms total

Five systems you would otherwise buy, integrate and keep in sync separately — inside one request

The control plane

Everything above, already built

This is the console your team gets on day one — the screens you would otherwise spend a quarter building, for every part of identity your product touches

Auth/Users⌘K

Users

Everyone who has an identity in this project.

New user

User	Status	Created	Last sign in
ALAda Lovelace[email protected]	Active	4 months ago	2 minutes ago
GHGrace Hopper[email protected]	Active	3 months ago	18 minutes ago
ATAlan Turing[email protected]	Active	2 months ago	3 hours ago
KJKatherine Johnson[email protected]	Not confirmed	6 days ago	never
RPRadia Perlman[email protected]	Banned	1 year ago	9 days ago

SeamsWhat you would build yourself

Stop stitching together identity infrastructure

Most SaaS teams end up integrating multiple vendors just to manage users, permissions, invitations, communications and audit logs

5 vendors · 10 integrations to own

Auth Provider
Authorization Provider
Email Provider
SMS Provider
Audit Logs

1 vendor · 0 integrations

One platform

The cost is not the vendors. It is the seams between them

What you actually needed to do

Stitched togetherOne platform

Put a role in the access token

Write glue at the issuer for every claim you need.

A claims template you preview against a real user.

Change the invitation email

The flow lives in one vendor, the template in another.

One template, per channel and per language.

Answer who changed what, and when

Join audit trails from five systems that disagree on time.

One trail with actor, target and category.

Promote a config change to production

Repeat it by hand in every vendor and hope nothing drifted.

Compare two environments and merge the diff.

PlatformWhat ships instead

Built as one system, not assembled from five

The infrastructure under your product

Six layers that ship together, instead of six vendors you assemble

Auth Infrastructure

Email, phone or username sign-in with multi-factor flows and the social providers your users already have

passwords
email · sms otp
totp
11 providers
sessions

Explore

Authorization Engine

Roles are scoped to an organization, so a permission means something specific for each customer

roles
scopes
grants
contexts
invitations

Explore

OAuth & OIDC

Every project is a standards-compliant issuer with discovery, JWKS and dynamic client registration

discovery
jwks
pkce
consent
dynamic registration

Explore

Edge Network

Edge functions on a Deno runtime with npm support, an in-browser editor and versioned deploys

deno
npm
versioned deploys
rollback
secrets

Explore

Communications

Email and SMS wired to identity events, with templates per channel and per language

email
sms
webhook
templates
per language

Explore

Observability & Audit

Traffic and performance on one side, a searchable request history and audit trail on the other

traffic
performance
audit trail
log query

Explore

Launch your own OAuth ecosystem

Create applications, manage consent flows, authorize third-party integrations and operate your own OAuth server

/.well-known/openid-configuration

{  "issuer": "https://acme.nulvless.app",
  "authorization_endpoint": "/oauth/authorize",
  "token_endpoint": "/oauth/token",
  "userinfo_endpoint": "/oauth/userinfo",
  "jwks_uri": "/.well-known/jwks.json",
  "scopes_supported": ["openid", "profile", "email", "offline_access"],
  "code_challenge_methods_supported": ["S256"],
}

Every project is an issuer from the first minute — any standards-compliant client can discover it without a line of glue

The questions a security review asks

Not how people sign in — how you prove what happened afterwards. Every change and every request carries an actor, a target and a time

Organization/Audit logs⌘K

Audit logs

Who changed what, in which environment, and when.

Action	Actor	Category	When	Target
Rotated secret key	AdAda Lovelace[email protected]	security	yesterday at 14:02	api_keysk-a91c07d5
Promoted development to production	AdAda Lovelace[email protected]	environments	yesterday at 11:41	environmentmain
Granted role admin	GrGrace Hopper[email protected]	permissions	2 days ago	userusr_9de2b710
Enabled provider apple	AlAlan Turing[email protected]	auth	3 days ago	projectacme-web
Deleted environment preview/checkout	AlAlan Turing[email protected]	environments	4 days ago	environmentpreview-checkout
Added redirect URL	GrGrace Hopper[email protected]	settings	6 days ago	projectacme-web

Audit trail

Every configuration change recorded with actor, target and category

Request history

A searchable trail of individual requests, not only aggregate counts

Keys per environment

An API key belongs to one environment, so a test key cannot reach production

Redirect allowlist

Sign-in returns only to the URLs listed for that environment

Traffic and performance

Traffic and error rates charted next to the requests behind them

Isolated environments

Staging and production never share state, users or keys

Every call is typed, every failure has a code

Typed SDKs, an error code for every failure, and framework quickstarts that end with a signed-in user

Verify

const { data: verified } = await nulvless.auth.verify({
  resource: "proj_16tbwq34",
  roles: ["owner", "admin"],
});

Verified

{
  "data": {
    "user": { "id": "usr_4c81f0a2" },
    "session": {
      "id": "ses_7b31d0",
      "amr": [{ "method": "password" }, { "method": "totp" }],
      "scopes": ["projects:write"]
    }
  },
  "error": null
}

OperatingWhat running it looks like

One control plane, from organization to request

Organizations hold projects, projects hold environments, and every identity decision is inspectable down to the individual request

Merge environment states

Succeeded1.13s

Initialize
188ms
Promote authentication
653ms
Promote communications
285ms

staging: staging; production
Deployment: n5s6mmy3b7ns4cmrh9aeen8h

Identity configuration promotes like code. Every environment has its own host, every promotion is a deployment you can inspect

Customers and teams

Organization

Members · Billing · Usage · Audit logs · Settings

Identity and access

Project

Users · Roles · Providers · Protection · Rate limits · Token claims

Environments and releases

Environments

Environments · Compare · Deployments · Redirects · API keys

Traffic and history

Observability

Traffic · Performance · Network · Audience · Services · Log query

             %+[/0=       
            #{<&*}>%      
         +    ]\1$#{<&    
       #{<&*    [/0=]\1$  
     [/0=]\1$     }>%+[/0=
   {<&*}>%+         {<&*}>
 /0=]\1$#          0=]\1$#
&*}>%+[          &*}>%+[/ 
\1$#{<         =]\1$#{<   
+[/0=]\1     *}>%+[/0     
  *}>%+[/0    $#{<&       
    #{<&*}>%    =         
      ]\1$#{<&            
        [/0=]\

One platform, from your first user

Focus on your product. We handle identity infrastructure

Start for free Read the docs

What you would have built

Six areas, every one of them a project of its own.

Authenticationpasswords, providers, MFA, sessions
AuthorizationRBAC, scopes, per-resource grants
OAuth serverOIDC discovery, JWKS, PKCE
Edge functionsDeno runtime, deploys, rollback
Notificationstemplates, providers, delivery logs
Observabilitymonitoring, audit trail, query

Roughly9 engineer-months · $135,000You start at$0