Question 1

What is Authreads, in one sentence?

Accepted Answer

Authreads is a multi-tenant identity platform: hosted login, tenant isolation, session management, and machine identity for products that serve more than one customer, built on OpenID Connect, OAuth 2.0, and WebAuthn rather than a private protocol.

Question 2

Who is Authreads actually for?

Accepted Answer

Teams building a product with more than one tenant: a B2B SaaS platform, an internal platform serving multiple business units, or a product that needs to isolate one customer's users, sessions, and policy from every other customer's. If your product only ever has one set of users, a simpler single-tenant auth solution is probably a better fit.

Question 3

How do I get started with Authreads?

Accepted Answer

Contact us and tell us what you're building. We'll talk through your tenancy model, timeline, and security requirements, and walk you through how the platform maps onto what you need. See the roadmap for the current state of each capability.

Question 4

Do you already have customers running in production?

Accepted Answer

We don't publish customer counts or names on this site: an unverifiable number wouldn't tell you anything useful, and a specific count would be out of date within a quarter. What we will tell you directly, if you ask, is the current maturity of the platform and whether it fits what you're building.

Question 5

How is Authreads different from building authentication in-house?

Accepted Answer

Building auth in-house means your team owns password storage, session lifecycle, tenant isolation, recovery flows, and every edge case in each of those, indefinitely. Authreads owns that layer instead, built to the same standards a security reviewer would expect from a dedicated identity team, so your team spends its time on the product rather than re-implementing login for the fifth time.

Question 6

How is Authreads different from a general-purpose auth-as-a-service product?

Accepted Answer

Multi-tenancy is the starting design constraint, not a feature bolted on later. Tenant isolation is enforced at the data layer for every tenant on the platform, per-tenant policy (password rules, session lifetimes, branding) is a first-class concept, and machine/agent identity (sender-constrained tokens via DPoP and Token Exchange) is built in rather than a separate product.

Question 7

What's the difference between hosted login and the first-party API, and which should I use?

Accepted Answer

Hosted login redirects your users to an Authreads-hosted screen (branded as your product) and returns a standard OpenID Connect authorization code. Pick this if you want the fastest path and don't need a custom login UI. The first-party API lets you build your own login form and drive verification, one-time codes, and session issuance directly. Pick this if pixel-level control of the sign-in screen matters to you. Both reach the same user pool and the same session model.

Question 8

Can we use Authreads for our own team's internal sign-in, separate from our customers?

Accepted Answer

Yes. A tenant is just a scoped identity boundary, and there's nothing that requires a tenant to be an external customer. Some teams use one tenant for their own staff and separate tenants per customer; talk to us about the shape that fits your org chart.

Question 9

What happens if we outgrow Authreads or need to migrate away later?

Accepted Answer

Because the platform is built on open standards rather than a proprietary protocol, your integration code (an OpenID Connect client, a WebAuthn relying party) is portable knowledge, not Authreads-specific lock-in. Data export and transition support are part of the agreement negotiated with each tenant: ask directly if this matters for your evaluation.

Question 10

Why publish a roadmap that shows what isn't finished yet?

Accepted Answer

Because hiding it would be worse. A buyer who discovers a missing capability after signing a contract loses more trust than one who saw "Planned" on the roadmap up front. We'd rather filter for the buyers who value that honesty than win a deal on an implied claim we can't back.

Question 11

Can we embed the login experience directly in our product instead of redirecting to a hosted page?

Accepted Answer

Yes, that's what the first-party API is for: you build the login form and its surrounding UI yourself, and call Authreads to verify credentials, issue one-time codes, and start sessions, so nothing has to leave your product's own domain or visual design. Hosted login is the faster path if a redirect is acceptable; the first-party API is the one to reach for when pixel-level control matters more than integration speed.

Question 12

Do you support multiple brands or products under one company account?

Accepted Answer

Yes. A tenant is a branding boundary as well as a data boundary, so a company running two distinct products can configure two tenants with separate users, login presentation, and logos even though both roll up to the same commercial relationship. Talk to us about how you want tenants structured relative to your own product lines.

Question 13

What's the accessibility posture of Authreads's own interfaces, not just the palettes tenants configure?

Accepted Answer

The same bar applies both ways. Every tenant-configured brand palette is checked against WCAG AA contrast before it can go live on a hosted login page, and Authreads's own hosted screens and this site are built to that same standard: full keyboard operability, visible focus states, correct heading order, and real alt text, not palettes or layouts that merely look accessible.

Question 14

How would we migrate to Authreads from whatever identity provider we're using today?

Accepted Answer

It depends what you're moving off of, but the general shape is consistent: users and their password hashes (or a forced reset if the source system can't export a compatible hash) come across, sessions get re-established the first time each user signs in on the new system, and your integration code changes to point at Authreads's OpenID Connect endpoints instead of the old provider's. Tell us what you're migrating from in the contact form and we'll walk through the specific steps and what has to happen in what order.

Question 15

Who actually handles our end users' passwords?

Accepted Answer

Authreads does, on your product's behalf. When your product uses hosted login or the first-party API, the credential verification step happens inside Authreads, and only a one-way cryptographic digest of a password is ever stored, never the password itself in a recoverable form. Full detail is on the security page, the same page every hosted login screen links to.

Question 16

Is our tenant's data actually isolated from every other tenant on the platform?

Accepted Answer

Yes, and it's enforced at the data layer rather than only in application code: a request scoped to one tenant is structurally unable to read or write another tenant's users, sessions, or policy, even if a handler upstream had a bug. This is described in more detail on the platform and trust pages.

Question 17

Do you hold SOC 2, ISO 27001, or another formal certification?

Accepted Answer

No, not currently, and we say so plainly rather than imply otherwise. Authreads is built with HIPAA-aware design principles (tenant isolation, data minimisation, audit trails), but we don't hold a third-party audit attestation today. If a specific certification is a hard requirement for your evaluation, tell us directly and we'll give you the current, honest answer.

Question 18

What happens during a security incident that affects our tenant's data?

Accepted Answer

The affected tenant is the first party notified, since you're best placed to decide what your own users need to hear and when. We aim to notify without unreasonable delay once an incident is confirmed and its scope is understood, and to give you enough detail to make your own notification decisions. See the trust page for the full incident process.

Question 19

How do I report a security vulnerability?

Accepted Answer

Email support@authreads.com with "Security" in the subject line and enough detail to reproduce the issue. We don't currently run a formal bug bounty program or commit to a fixed response SLA, but every genuine report is read and acted on. See the security page for the full process.

Question 20

What personal data does the Authreads marketing site itself collect?

Accepted Answer

Just what the contact form collects (name, work email, company, role, message, and how you heard about us), plus the submitting IP address and user agent for abuse prevention. This site and the developer portal can use Google Analytics (first-party analytics cookies, IP anonymised), but only if you accept when asked — decline or ignore the prompt and no analytics script is fetched and no analytics cookie is set. There are no advertising cookies. See the privacy page for the full breakdown.

Question 21

How long is our data retained?

Accepted Answer

It depends what data. Contact-form submissions on this site are retained for exactly 365 days and then deleted automatically; that's a figure we commit to and enforce, not just describe. Retention for data processed on a tenant's behalf is bounded by policy and set out in the tenant's own agreement; see the trust page for the general posture.

Question 22

Do you sell or share our data with third parties?

Accepted Answer

No, we don't sell personal data. We use a small number of sub-processors (disclosed by category and purpose on the sub-processors page) strictly to deliver functionality like transactional email, never to share data for marketing or resale.

Question 23

What standards is authentication actually built on?

Accepted Answer

OpenID Connect and OAuth 2.0 for login flows, PKCE for the authorization code exchange, WebAuthn for passkeys, DPoP (RFC 9449) for sender-constrained tokens, and Token Exchange (RFC 8693) for delegated machine credentials, with SAML and SCIM planned for enterprise federation and provisioning. Every one of those is a named, public specification a security reviewer can independently verify.

Question 24

How are machine and agent credentials kept secure?

Accepted Answer

Machine and agent tokens are sender-constrained using DPoP (RFC 9449), so a captured token is useless without the private key that requested it, and scoped narrowly using Token Exchange (RFC 8693) rather than services forwarding their own broad credential downstream. See the platform page for the full picture.

Question 25

Is data encrypted in transit and at rest?

Accepted Answer

Yes: all traffic to and from the platform is encrypted in transit, and data at rest is protected with industry-standard encryption controls. We don't publish the specific implementation of either, consistent with not disclosing infrastructure detail publicly, but it's a standard part of the security review we'll walk through directly.

Question 26

I received an unexpected security email from Authreads. Is it legitimate?

Accepted Answer

Authreads sends transactional security email (sign-in codes, password resets, new-device or session alerts) only in response to an action on an account you or someone else initiated. If something looks wrong, don't click any link in it. Instead go directly to the product you use and check your account from there, or email support@authreads.com if you suspect the message itself is fraudulent.

Question 27

How is tenant isolation actually proven, not just asserted?

Accepted Answer

Isolation is enforced at the data layer, meaning every read and write is scoped to a tenant as a structural property of how requests are handled, not a check an individual engineer has to remember to add in application code. That's a different claim from "we're careful": it's a design constraint that makes a cross-tenant leak require breaking the platform's core request path, not one missed guard clause in one handler. We'll walk through the specific mechanism directly with a security reviewer as part of an evaluation.

Question 28

Can we choose which region our tenant's data is stored in?

Accepted Answer

Not as a selectable option today. We don't currently offer per-tenant region selection or data residency guarantees as a standard feature. If a specific residency requirement is a hard condition for your evaluation, raise it directly: we'd rather tell you plainly that it isn't available yet than imply it is.

Question 29

What happens to a user's account and sessions the moment they're offboarded from our tenant?

Accepted Answer

As soon as your product disables or removes a user, their existing sessions stop being usable at the next check of that session, not on a delayed sweep or their natural expiry. What happens to the underlying account record after that, immediate deletion versus a retention window before deletion, is governed by your tenant's own data handling policy, since different products need different retention for their own compliance reasons.

Question 30

Is our tenant's audit trail something we can rely on, or something that could quietly be edited?

Accepted Answer

Security and audit events (sign-in, recovery, session revocation, administrative changes) are recorded as they happen and aren't something an ordinary support interaction can retroactively edit. We treat the audit trail as evidence, not a log that gets tidied up after the fact; see the trust page for the full posture on what's recorded and how long it's kept.

Question 31

What OAuth grant types and flows are actually supported?

Accepted Answer

Authorization code with PKCE for interactive logins, and Token Exchange (RFC 8693) for delegated machine and agent credentials. Grant types that current OAuth guidance treats as insecure for new applications, like the implicit flow or resource owner password credentials, aren't offered, on purpose: we'd rather not expose a flow we'd have to advise you against using.

Question 32

Does Authreads ever see or log the plaintext of a password we submit?

Accepted Answer

No. A password is verified and immediately reduced to a one-way cryptographic digest; the plaintext value is never written to a log, a database column, or any other durable store. That's the same handling whether the credential comes through hosted login or the first-party API.

Question 33

If we ask you to delete our tenant entirely, what actually happens?

Accepted Answer

Tenant offboarding and the resulting data deletion are handled as part of winding down the agreement with our team, since the timing and scope, immediate deletion versus a defined retention window for your own compliance needs, depend on what you agreed to when you onboarded. Ask directly if this is a requirement you want settled in writing before you integrate.

Question 34

What protocols and standards does the API actually speak?

Accepted Answer

OpenID Connect and OAuth 2.0 (authorization code with PKCE) for the hosted login path, a first-party REST API for products building their own login screen, WebAuthn for passkeys, and DPoP/Token Exchange for machine identity. Nothing proprietary sits between your integration and the standard it's built on.

Question 35

Do you support passkeys today?

Accepted Answer

Passkey support (WebAuthn) is on the roadmap as planned rather than available today. Password-based login, one-time codes, and multi-factor verification are the available sign-in methods right now; check the roadmap for the current state.

Question 36

Do you support SAML or SCIM for enterprise customers?

Accepted Answer

Not yet. Both are on the roadmap as planned, for enterprise federation (SAML) and automated user provisioning (SCIM). If either is a near-term requirement for you, tell us directly so we can talk through timing honestly.

Question 37

Can we fully brand the hosted login page as our own product?

Accepted Answer

Yes. Logo, color, and copy on the hosted login screen come from your tenant's own configuration, reviewed against WCAG AA contrast before it can go live. A brand palette that fails accessibility is rejected rather than shipped with a warning; that check runs the same way for every tenant.

Question 38

Can we put the hosted login page on our own domain?

Accepted Answer

Not today. Custom login domains are in progress and will not be presented as available until a real tenant-hosted login has passed the full release verification. Your OpenID Connect issuer, endpoints, client credentials, and registered redirect URIs will remain unchanged when the login hostname later moves.

Question 39

How do sessions behave if a user moves between multiple apps under the same tenant?

Accepted Answer

Session policy (idle timeout, absolute expiry, revocation) is set per tenant and applies consistently across whatever applications sit under that tenant. The specific mechanics for sharing or separating sessions between multiple apps in one tenant are part of the integration conversation, since they depend on your architecture.

Question 40

What does "tenant" mean technically, not just conceptually?

Accepted Answer

A tenant is an isolated identity boundary: its own users, sessions, security policy, and branding, scoped so a request for one tenant cannot read or write another tenant's data. It's the unit everything else in the platform (login, policy, branding, machine identity) is configured against.

Question 41

Is there an official SDK, or do we call the API directly?

Accepted Answer

The API is a standard REST and OpenID Connect surface, usable with any HTTP client or OIDC-conformant library rather than requiring a proprietary SDK. Worked examples in curl, JavaScript, and Python live in the developer portal.

Question 42

How do we test an integration before going live?

Accepted Answer

Each tenant gets credentials scoped to a non-production environment for exactly this. The developer portal's onboarding guide walks through issuing test credentials, driving a login flow end to end, and what to check before switching to production credentials.

Question 43

What happens to a user's other sessions when we revoke one?

Accepted Answer

Revocation is scoped to what you ask for (a single session, or every session for that user) and takes effect on the next verification of the affected session, not on its natural expiry. A user or tenant administrator can see the full device/session inventory and revoke from there as well.

Question 44

Where does identity end and authorization begin?

Accepted Answer

Authreads answers "is this a real, authenticated user of this tenant": authentication. What that user is allowed to do inside your product (authorization) is enforced by your application today, informed by claims Authreads issues in the token. Fine-grained authorization as a platform capability is on the roadmap as planned.

Question 45

What does passkey support, once it ships, actually change for our users?

Accepted Answer

It removes the password as the thing an attacker needs to steal. A passkey is a public-key credential bound to a user's device or platform authenticator; a stolen credential database or a phishing page can't extract anything reusable from it the way a stolen password digest or a captured one-time code can be. Password-based login, one-time codes, and multi-factor verification remain the available sign-in methods until passkeys ship; check the roadmap for current state.

Question 46

Can one person belong to more than one of our tenants, or more than one tenant across different products?

Accepted Answer

Yes. A user identity isn't locked to a single tenant by the platform's data model; the same person can hold a separate account in each tenant they're a member of. Whether you treat that as the same person across tenants or as entirely separate accounts is a product decision on your side, not a platform limitation.

Question 47

If we run multiple brands, how does tenant branding work?

Accepted Answer

Each tenant configures its own branding (logo, color, and copy) independently, so two tenants under the same commercial relationship can look different to their respective end users. Custom login domains are still in progress; when available, changing the hosted login hostname will not change either tenant's OpenID Connect integration.

Question 48

Can we require MFA or passkeys for some users and not others?

Accepted Answer

Session and authentication policy is set per tenant, and a tenant's policy can require stronger verification for specific roles or conditions rather than applying one blanket rule to every user. The specific configuration options depend on which verification methods are available at the time, so check the roadmap for what's live today and confirm the details directly for your rollout.

Question 49

What claims actually show up in the token we receive after a user signs in?

Accepted Answer

The standard OpenID Connect claims (subject identifier, issued and expiry times, and the requested scopes) plus tenant-scoped claims that identify which tenant the user authenticated against. Authorization decisions inside your product, what that user is allowed to do, are built on top of those claims by your application; Authreads doesn't try to guess your permission model for you.

Question 50

How do machine and agent clients authenticate differently from a human user?

Accepted Answer

A human authenticates interactively, through hosted login or the first-party API, and ends up with a session bound to that sign-in. A machine or agent client instead holds a credential that's exchanged for a sender-constrained, narrowly scoped token using DPoP (RFC 9449) and Token Exchange (RFC 8693), so the resulting token is useless if intercepted and doesn't carry more privilege than the specific action it was issued for. Neither path shares a session with the other.

Question 51

What happens if we need to rotate a client credential or a signing key on our side?

Accepted Answer

Key and credential rotation is supported with a bounded overlap window, so an old and a new credential can both stay valid briefly while you roll the change out, rather than forcing a hard cutover that breaks anything mid-rotation. Reach out through support or the developer portal when you need to rotate, and we'll walk through the specific steps for your integration.

Question 52

Is there rate limiting on public endpoints?

Accepted Answer

Yes. Public, unauthenticated write paths (like login attempts and the contact form) are rate-limited per IP address and per account/email, evaluated before any database access. We don't publish the exact thresholds, since doing so mainly helps someone tune an attack to stay just under them.

Question 53

If the identity platform has a problem, does login fail open or closed?

Accepted Answer

It fails visibly rather than open. "Fail visibly" is one of our core engineering principles: a misconfiguration or dependency failure stops the affected request rather than quietly degrading into a less-secure state that nobody notices until it's an incident.

Question 54

Is there a public status page?

Accepted Answer

Not yet, and we say so plainly rather than link to something that doesn't exist. If you think you're seeing a platform-wide issue, contact us directly and we'll tell you what we know. See the status page.

Question 55

What SLA or uptime commitment do you offer?

Accepted Answer

We don't publish an uptime figure or SLA on this site, because we don't have one we're ready to commit to publicly yet. If a specific uptime commitment is a requirement for your evaluation, that's exactly the kind of thing to raise directly so we can give you an honest answer.

Question 56

How do we get support if something breaks in production?

Accepted Answer

Support for a live tenant is handled through the channel set up as part of your agreement with us, typically a direct line to the team, not a public ticket queue. This site's contact form is the right starting point if you don't already have that channel established.

Question 57

Can we export our tenant's data if we need to?

Accepted Answer

Data portability and export are addressed in the agreement negotiated with each tenant, since the specifics depend on what you're exporting and why. Ask directly if this is a requirement for your evaluation: we'd rather set expectations up front than after you've integrated.

Question 58

Will we be notified before planned maintenance?

Accepted Answer

Maintenance communication is part of the operational relationship set up with each tenant: notice windows and channels are agreed directly rather than published as a blanket policy here.

Question 59

How do password reset and account recovery work operationally?

Accepted Answer

Reset and recovery links and one-time codes are single-use and short-lived, invalidated the moment they're used or when they expire, whichever comes first. Your product controls when a reset flow is triggered; Authreads handles verification, issuance, and the resulting session.

Question 60

How do we know if something in our integration is misconfigured?

Accepted Answer

Consistent with "fail visibly," a misconfiguration on a request path stops that request with a specific, typed error rather than succeeding incorrectly or silently falling back. The developer portal's API reference documents the error shapes so your integration can distinguish a configuration problem from a genuine runtime failure.

Question 61

Who monitors the platform, and how?

Accepted Answer

Security-relevant events (sign-in, recovery, session revocation, administrative changes) are logged and monitored as part of running the platform, with access restricted to what operating it requires. We don't publish operational monitoring architecture publicly, consistent with keeping implementation detail off this site.

Question 62

Can we deprovision or offboard users programmatically, or only one at a time through a UI?

Accepted Answer

Deprovisioning is available through the API, so your product can disable a user or revoke their sessions as part of your own offboarding workflow rather than requiring someone to do it by hand for every user. That's the same primitive whether you're removing one user or working through a bulk export from an HR or provisioning system upstream.

Question 63

How would we actually find out about an incident, beyond what the trust page describes in general terms?

Accepted Answer

Direct notification to your tenant's registered contact, not a public status post you'd have to go looking for. We aim to notify without unreasonable delay once an incident is confirmed and scoped, with enough detail for you to make your own downstream notification decisions. There's no public incident history published on this site today; ask directly if you want to understand the process in more depth before you commit.

Question 64

Can we pull an audit log ourselves for our own compliance reporting, or do we have to ask you for it?

Accepted Answer

That depends on what's built at the time you need it; audit log export as a self-service capability is part of the platform's maturity curve rather than something we can promise universally today. Ask directly what's available for your tenant: we'd rather give you the current, specific answer than a generic yes.

Straight answers,
not a sales page.

Evaluating

Security and privacy

Integration

Operations

Commercial