Security at auth.is
Identity is the front door, so security is the product. auth.is is built as a standards-compliant OIDC provider with tenant isolation, encrypted keys, and short-lived tokens at its core. Below is our security posture and how to report anything you find.
Our security posture
Per-issuer tenant isolation
Every team gets its own issuer with its own user pool and signing keys. A user, their credentials, and their federated links belong to exactly one issuer — they never cross tenants.
Signing keys encrypted at rest
Private signing keys are encrypted at rest and never leave the service in plaintext. They are decrypted only in memory when an issuer signs, and are never logged or returned by any API.
Zero-downtime key rotation
Keys rotate without downtime: a new key is published in the issuer JWKS before it becomes active, and a retired key stays published until the last token it signed has expired — so verification never breaks mid-rotation.
PKCE required by default
Authorization Code flow with PKCE is required by default for clients, closing off authorization-code interception. Public clients are PKCE-only.
Passkeys scoped to each issuer
WebAuthn passkeys are bound to the issuer host as their relying-party ID, giving tenant isolation at the credential level — a passkey registered for one issuer cannot be used against another.
Short-lived, audience-bound tokens
Access tokens are short-lived JWTs bound to their intended audience (resource), so a token minted for one service is not silently accepted by another.
Credentials never handed to your tools
Management happens over the MCP via a standard OAuth sign-in — your AI tools never see your password. End-user passwords are stored only as argon2id hashes, never in plain text.
Isolated, rate-limited endpoints
Subdomain issuers keep each tenant’s cookies and sessions naturally isolated. Authentication and registration endpoints are rate-limited, and login responses are generic so they cannot be used to probe whether an account exists.
auth.is is in beta and we are still hardening the product. This page describes our security capabilities at a high level rather than exact parameters; if you need specifics for a security review, reach out.
Responsible disclosure
We welcome reports from security researchers and treat them as a priority. If you believe you have found a vulnerability, please tell us before disclosing it publicly, and give us a reasonable window to fix it.
How to report
Email [email protected] with enough detail to reproduce the issue — affected endpoint or host, steps, and impact. We will acknowledge your report and keep you updated as we investigate and remediate. This policy is also published at /.well-known/security.txt.
Scope
In scope: the auth.is service and its issuer hosts (*.auth.is), the MCP server at mcp.auth.is, the API, and this site. Please do not run tests that degrade the service for others (denial-of-service, spam, or bulk automated scanning), and never access, modify, or exfiltrate data belonging to another tenant or user — use your own test issuer.
Safe harbor
If you make a good-faith effort to comply with this policy during your research, we will consider your testing authorized, will not pursue or support legal action against you, and will work with you to understand and resolve the issue quickly. If in doubt about whether something is in scope or permitted, ask us first at [email protected].
Recognition
We do not run a paid bug-bounty program during beta, but we are grateful for every report. With your permission, we are happy to publicly credit researchers who responsibly disclose valid issues.