Every way in, handled
Passwords, providers, passwordless and MFA behind one SDK call — with the settings, limits and user records that a real product needs on day one
Users
Everyone who has an identity in this project.
| 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 |
Ways in
Social login
Turn methods on per environment. The client picks them up without a redeploy, and users keep one identity across all of them
Providers are per environment — the client reads them at runtime, so enabling Apple is a setting, not a release
Email and password
Password policy, breach checks and reset flows, with hashing you never have to pick
Social providers
Google, GitHub, Apple and the rest, configured per environment
Passwordless
Magic links and one-time codes over email or SMS
Multi-factor
TOTP and recovery codes, enforced globally or per role
Sudo mode
Elevate a single action with a one-time nonce instead of the whole session
Sessions
Device, location and method recorded on every session, revocable one by one
Protection
The parts you would otherwise bolt on after the first incident, already in the box
Rate limits
Per endpoint, per identifier, per environment — with the counters visible
Bot protection
Challenge sign-up and sign-in without shipping a captcha yourself
Sign-up controls
Allowlists, blocked domains, invitation-only projects and waitlists
Breach detection
Known-compromised passwords rejected at the moment they are set
Ada LovelaceActive
usr_4c81f0a2 · [email protected]
Open a user and every session is there: device, city, assurance level, and which factors they actually hold
The user record
A real table, not an opaque blob. Search it, filter it, open a user and see everything attached to them
Requests
Every call the platform served, as it happened.
| Time | Method | Status | Source | Path | Message |
|---|---|---|---|---|---|
| 12:04:11.204 | POST | 200 | gateway | /auth/signin | session issued |
| 12:04:10.881 | GET | 200 | gateway | /.well-known/jwks.json | cached |
| 12:04:09.117 | POST | 401 | gateway | /auth/signin | invalid credentials |
| 12:04:08.640 | POST | 200 | oauth | /oauth/token | authorization_code exchanged |
| 12:04:07.019 | POST | 429 | gateway | /auth/signin | rate limit exceeded |
| 12:04:05.552 | POST | 502 | functions | /functions/webhook-relay | upstream unavailable |
| 12:04:04.238 | GET | 200 | gateway | /auth/session | session verified |
| 12:04:02.907 | POST | 202 | notifications | /notifications/send | email queued · email-otp-verification |
Every sign-in attempt lands in the same request trail, with the reason it failed attached
Search and filter
By email, provider, status or metadata, across millions of rows
Linked identities
One user, every provider they have ever signed in with
Metadata
App metadata you control and user metadata they control, kept apart
Suspend and ban
Cut access immediately without deleting the history behind it
Ask again, right before it matters
A valid session is not the same as intent. Sudo mode puts a fresh check in front of the actions that would hurt — and the same check is available to the actions your own product considers dangerous
Protected actions
MFA, credentials, permissions, identities, sessions and passwords, each toggled on or off
Your own actions
Guard anything in your API with the SDK — deleting a key, wiring a payout, exporting data
Timeout
One confirmation elevates the session for a window you set, then it lapses on its own
Single-use nonce
Or authorize exactly one call, without elevating the session at all
Any factor
TOTP, email code or SMS — whichever the user actually has
Visible in the session
Sudo state and its expiry sit on the session, next to device and location
Sudo Mode
An extra layer of confirmation in front of sensitive actions.
Confirm your access
Or send the code by SMS. After confirming, protected actions run without asking again until the timeout expires.
You choose which actions demand a fresh confirmation, and how long one confirmation lasts
One call in, one call to check
The SDK returns a discriminated result instead of throwing, so the failure path is something you handle rather than something you catch.
const { data: verified } = await nulvless.auth.verify({
resource: "proj_16tbwq34",
roles: ["owner", "admin"],
});One platform, from your first user
Focus on your product. We handle identity infrastructure
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