Drop a “Sign in with Chirp” button into your app in five minutes. It’s standard OpenID Connect, with two differences from Auth0 / Clerk: you never receive the user’s email, and the user ID you get is unique to your app — so there’s no cross-app profile of your users for anyone to leak, sell, or subpoena.
Drop in any OIDC client — nothing else to learn. Test against real, signed tokens before you have a single user. Hosted, or self-host the exact same open-source code — no lock-in either way.
Free for up to 20 users · no credit card · AGPL-3.0 open source
Register an app, drop in the button, handle the callback. Any standards-compliant OIDC client works.
/dashboard → New app name myapp.com redirect_uri https://myapp.com/auth/cb → client_id cs_dev_7f3a09c2… (public PKCE client — no secret)
const chirp = await Issuer.discover(
'https://signin.chirpauth.com');
app.get('/login', (req, res) => res.redirect(
client.authorizationUrl({ scope: 'openid',
code_challenge_method: 'S256' })));POST /token grant_type=authorization_code&code=<one-time>&code_verifier=<pkce>
→ { "id_token": "<jwt>", "token_type": "Bearer", "expires_in": 3600 }That's it — verify the RS256 JWT against our JWKS and you know who signed in. Full quickstart, plus iOS & Android →
Mint a genuine, RS256-signed ID token for your own app with one request. Pipe it straight into your callback and prove your token verification works — before you onboard a single real user, with no email round-trip.
Test tokens carry a test claim and a test:-namespaced subject, so they can never impersonate a real user at any relying party. Safe to use in CI.
$ curl -X POST -H "Authorization: Bearer $ID_TOKEN" \
-d '{"client_id":"cs_dev_…","sub":"test:alice"}' \
https://signin.chirpauth.com/control/apps/test-tokens
eyJhbGciOiJSUzI1NiIs… # a real signed JWT
# pipe it straight at your own callback:
$ curl -H "Authorization: Bearer <that jwt>" \
https://myapp.com/auth/cbThe two differences are the whole reason to choose Chirp. You get a stable per-user ID scoped to your app — a pairwise sub derived by HMAC from the user id and your app id — and you never hold their email. So you can’t leak it, sell it, or be subpoenaed for it; and two apps comparing notes can’t tell they share a user. A cross-app profile of your users simply never exists.
Everything else is the same OIDC you already know. No social-login aggregation, no analytics pixels, only transactional email. Your users sign in with a short-lived email link or a passkey — you never see or choose which.
It's an identity provider — you shouldn't take its security on faith. The whole thing is AGPL-3.0 on GitHub. Read it before you trust it.
The hosted service runs the exact source in the repo. No proprietary fork, no “enterprise” black box.
If we ever disappoint you — or just disappear — self-host the same code in your own AWS account. Standard OIDC means your apps don't change.
Build and launch on Free — up to 20 users, unlimited apps, no card. When you grow past 20, flip one switch to Pro. One subscription per account, not per app or per active user.
Or self-host the same code for $0, forever.
signin.chirpauth.com issuerPricing is per tenant — one subscription per Chirp account, no matter how many apps you register. The 20-identity Free cap counts distinct end users across all your apps combined. We don't bill per active user, because we don't track active users beyond the cap counter.
Self-host the same AGPL-3.0 code in your own AWS account. It's standard OIDC, so your apps keep working without a change. You're never stranded.
Any standards-compliant OIDC client works — openid-client, AppAuth, ASWebAuthenticationSession, whatever you already use. App registration and test tokens live in the dashboard and a plain HTTP control plane.
Yes — up to 20 users, unlimited apps, no card. Enough to build, test, and launch. You only pay when you grow past it.
A short-lived email link or a passkey (Face ID / Touch ID / hardware key). No passwords to leak, nothing to phish. The sign-in page and sender domain are the same for every Chirp app — one flow your users already know.
As little as possible: an email and what's needed to sign in. Identities are pairwise per app, and we keep no per-user sign-in history. No analytics, no selling. Read the policy.
No — on purpose. Sign-in always happens on signin.chirpauth.com and sign-in emails always come from the same sender, for every app. Users learn one legitimate domain, which makes look-alike phishing stand out. White-labeling auth would train them out of that.