Platform

Six primitives.
One identity layer.

Hosted login, tenant isolation, session lifecycle, machine identity, and branding, all enforced the same way for every tenant.

See the roadmap

Rows of illuminated equipment racks glowing blue in a dim technical room

Hosted login, or bring your own screen

Two integration paths reach the same user pool, so you pick the one that matches who renders the login screen, not two different backends.

Laptop screen glowing in a dim room, showing a clean sign-in interface

Hosted login

Redirect to an Authreads-hosted screen and get back an OpenID Connect authorization code that is PKCE-protected, standards-conformant, and usable from any OIDC client library. The hosted screen carries the tenant's own branding, not ours.

First-party API

Build your own login form and drive Authreads' API directly: credential verification, one-time codes, password reset, and session issuance.

Both paths end in the same place: a signed session your product can verify, and a user record that belongs to exactly one tenant.

Dim server vault with rows of cabinets lit by cool overhead strips

Tenant isolation enforced at the data layer

Multi-tenant identity fails in one specific way: a bug in application logic lets one tenant's request resolve another tenant's data. Authreads closes that path structurally: tenant scoping is enforced where the data lives, so a request for one tenant cannot read or write another tenant's users, sessions, or policy, even if a handler upstream forgot to check.

Per-tenant configuration (password policy, session lifetimes, notification behavior, branding) lives alongside that isolation boundary, so tenants can diverge in policy without ever sharing exposure.

Session management and revocation

Two properties that matter most once something has actually gone wrong.

Lifecycle, not just login

Sessions carry idle and absolute expiry, are visible to the user who holds them as a device and session inventory, and can be revoked individually or entirely, by the user, a tenant administrator, or your product through the API.

Built for real incidents

Revocation takes effect on the next verification, not on the credential's natural expiry, so an administrator who needs to end a session immediately doesn't wait for a token to time out on its own.

Machine identity

Credentials for services and agents, not just people

Server-to-server calls and autonomous agents need identity too, and static shared secrets are the wrong answer at any scale. Authreads issues sender-constrained tokens bound to a specific holder using DPoP (RFC 9449), so a stolen token is worthless without the key that requested it, and supports Token Exchange (RFC 8693) for a service to obtain a narrower, purpose-scoped token on behalf of a caller rather than reusing its own broad credential.

Sender-constrained

A captured token cannot be replayed from a different client: DPoP binds it to a private key held only by the original caller.

Single-use, short-lived

Machine credentials are scoped to a narrow lifetime and a narrow purpose, limiting the blast radius of a leak.

Delegated, not duplicated

Token Exchange lets a service request a token scoped to an operation, instead of forwarding its own full-privilege credential downstream.

Designer reviewing color swatches and layout proofs on a lightbox

A tenant's login screen looks like their product

Logo, color, and copy on the hosted login screen come from the tenant's own configuration, reviewed against WCAG AA contrast before it can go live. A brand palette that fails accessibility is rejected, not shipped with a warning.

Tenant-owned login hostnames are in progress and are not available today. The design keeps the OpenID Connect issuer and application configuration unchanged when that hostname moves.

Standards you can independently verify

Every claim above maps to a named, public specification. None of it requires trusting a vendor claim you can't check yourself.

OpenID ConnectOAuth 2.0 with PKCEWebAuthn passkeysDPoP, RFC 9449Token Exchange, RFC 8693SAML federationSCIM provisioning

OpenID Connect and OAuth 2.0 for the login flows, PKCE for the authorization code exchange, DPoP and Token Exchange for machine identity, WebAuthn for passkeys, and SAML/SCIM for enterprise federation and provisioning as they come online. See the roadmapfor what's available today versus planned.

The credential-handling detail (what's stored, for how long, and how to report a problem) lives on the security page. For API shape and integration mechanics, see Developers.

Ready to talk specifics?

Tell us about your tenancy model and we'll walk through how it maps onto the platform.

Six primitives.One identity layer.