Skip to content
Authreads

FAQ

Straight answers,
not a sales page.

What buyers, security reviewers, integrators, and operators actually ask before they sign, grouped so you can find yours fast.

Read the security page
Notebook and pen resting on a desk beside a cup of coffee, mid-review

Evaluating

What is Authreads, in one sentence?

Authreads is a multi-tenant identity platform: hosted login, tenant isolation, session management, and machine identity for products that serve more than one customer. Available login flows use OpenID Connect and OAuth 2.0, with passkeys, authenticator apps and one-time codes as sign-in methods; SAML and SCIM are planned rather than presented as shipped.

Who makes Authreads and where is it based?

Authreads is built and operated by Brishiv Tech Lab LLP, a limited liability partnership with its registered office in Ahmedabad, Gujarat, India. The company runs other products too; Authreads is its identity platform.

How does Authreads compare to Auth0, Clerk or Keycloak?

Each comparison page opens with where the alternative is the better choice. Auth0 is a general-purpose identity platform that can be configured for almost any requirement, including multi-tenancy, and has far more breadth, ecosystem and procurement history. Clerk is built around developer experience and drop-in UI for React and Next.js, and is faster to a first login. Self-hosted servers such as Keycloak give total control and data residency in exchange for owning upgrades, availability, key rotation and backups. Authreads is narrower on purpose: the tenant is the primary boundary, isolation is enforced at the data layer, and machine and agent identity uses DPoP and Token Exchange. It holds no SOC 2 or ISO 27001 certification today, and SAML and SCIM are planned, not available.

Who is Authreads actually for?

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.

How do I get started with Authreads?

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.

Do you already have customers running in production?

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.

How is Authreads different from building authentication in-house?

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.

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

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.

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

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.

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

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.

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

Because the available platform uses open standards rather than a proprietary login protocol, your OpenID Connect integration knowledge is portable rather than Authreads-specific, and passkeys use the W3C WebAuthn standard. Data export and transition support are part of the agreement negotiated with each tenant: ask directly if this matters for your evaluation.

Is Authreads open source?

No. Authreads is closed source (proprietary). It is free to sign up and use, and access is granted on request: email contact@authreads.com. Integrations aren't locked in: sign-in runs on the published OpenID Connect and OAuth 2.0 standards, and the API is documented publicly on the developer portal with a machine-readable OpenAPI document.

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

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.

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

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.

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

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.

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

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.

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

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.

Security and privacy

Who actually handles our end users' passwords?

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.

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

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.

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

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.

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

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.

How do I report a security vulnerability?

Email security@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.

What personal data does the Authreads marketing site itself collect?

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.

How long is our data retained?

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.

Do you sell or share our data with third parties?

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.

What standards is authentication actually built on?

Available capabilities use OpenID Connect and OAuth 2.0 for login flows, PKCE for the authorization code exchange, DPoP (RFC 9449) for sender-constrained tokens, and Token Exchange (RFC 8693) for delegated machine credentials, and WebAuthn for passkeys. SAML and SCIM are planned. Every named mechanism is a public specification a security reviewer can independently verify; the roadmap says which ones are live.

How are machine and agent credentials kept secure?

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.

Is data encrypted in transit and at rest?

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.

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

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.

How is tenant isolation actually proven, not just asserted?

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.

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

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.

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

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.

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

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.

What OAuth grant types and flows are actually supported?

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.

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

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.

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

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.

Integration

What protocols and standards does the API actually speak?

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, DPoP/Token Exchange for machine identity, and WebAuthn for passkeys. Sign-in strength is reported in the standard amr and acr claims and requested with acr_values; essential acr requests through the claims parameter are not supported. Nothing proprietary sits between today's hosted integration and the standards it uses.

Do you support passkeys today?

Yes. End users can register and sign in with WebAuthn passkeys on hosted login and through the API, alongside passwords, emailed one-time codes, authenticator apps (TOTP) and single-use recovery codes. Each tenant chooses which methods are allowed and can stage a requirement for a stronger method. Applications can require a passkey for a sign-in with acr_values. Authreads does not claim a NIST assurance level or third-party certification for these methods.

Do you support SAML or SCIM for enterprise customers?

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.

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

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.

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

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.

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

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.

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

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.

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

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.

How do we test an integration before going live?

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.

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

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.

Where does identity end and authorization begin?

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.

What does passkey support actually change for our users?

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. Passkeys are available today alongside passwords, one-time codes and authenticator apps; recovery still matters, so users can keep single-use recovery codes for a lost device.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

Operations

Is there rate limiting on public endpoints?

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.

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

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.

Is there a public status page?

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.

What SLA or uptime commitment do you offer?

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.

How do we get support if something breaks in production?

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.

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

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.

Will we be notified before planned maintenance?

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.

How do password reset and account recovery work operationally?

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.

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

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.

Who monitors the platform, and how?

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.

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

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.

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

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.

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

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.

If part of the platform has a problem, does it take down every tenant, or just the ones affected?

We don't publish the internal architecture that determines blast radius, consistent with keeping implementation detail off this site, but tenant isolation is a design principle that extends to how the platform is built and run, not only how data is stored. If continuity during a partial outage is a specific requirement for your evaluation, raise it directly.

Do key rotations or platform maintenance cause visible downtime for our users?

Rotations are designed with a bounded overlap window specifically so they don't require a hard cutover, and routine maintenance is planned to avoid disrupting active sessions. We don't publish a blanket maintenance-window policy on this site, since notice windows and channels are agreed per tenant.

Can we set our own session idle timeout and absolute expiry, or is that fixed platform-wide?

Session policy, including idle timeout and absolute expiry, is configured per tenant rather than fixed for the whole platform, so you can set it tighter or looser than another tenant based on your own risk tolerance. It applies consistently across whatever applications sit under your tenant once set.

Commercial

How much does Authreads cost?

Nothing. Authreads is free to sign up and use. Access is granted on request: email contact@authreads.com with roughly what you're building and we'll set you up.

Is there a free tier or trial?

Authreads is free, so there's no separate free tier and no time-limited trial. There's no self-serve sign-up either: email contact@authreads.com to request access and we'll set up what you need to actually try it.

How do we get a contract or a data processing agreement (DPA)?

Both are part of onboarding a tenant, put together directly with our team once we understand what you're building. Start with the contact form and mention that a DPA is a requirement: we'll make sure it's part of the conversation from the start, not an afterthought.

Is there a minimum commitment or contract length?

No. Authreads is free, so there's no minimum commitment and no contract length to sign up for. Access is granted on request: email contact@authreads.com.

Who do we contact for billing questions once we're a customer?

There's no billing: Authreads is free. For anything about your account or access, email contact@authreads.com, or support@authreads.com once you're live.

Can we run a pilot or proof-of-concept before committing to a full contract?

You don't need a pilot contract: Authreads is free to use. Email contact@authreads.com with what you're building and what you need to prove out, and we'll grant access and help you set up a test.

Is pricing based on users, tenants, logins, or something else?

Neither: Authreads is free, so there's no per-user, per-tenant or per-login charge. Access is granted on request by emailing contact@authreads.com.

What happens to our data if we terminate the agreement?

Ask us before you onboard and we'll agree export and deletion timelines with you up front, rather than leaving them to be figured out later. Email contact@authreads.com with your requirements.

Do you offer multi-year agreements, or is everything renewed annually?

Neither: Authreads is free, so there's no annual renewal or multi-year agreement to sign. Access is granted on request via contact@authreads.com.

Can we negotiate terms specific to a large or unusual deployment?

Yes. Authreads is free, but large or unusual deployments (scale, tenancy shape, compliance needs) still benefit from talking to us first. Email contact@authreads.com and describe what makes your deployment unusual; we'll shape the setup around it.

Still have a question that isn't here?

Ask directly, and we'll give you the honest current answer, not a rehearsed one.