Different by design: how Chirp differs from a typical OIDC provider

Most identity providers compete by adding. More scopes, more social connectors, dashboards, organizations and roles, white-label theming, per-seat add-ons. Chirp competes by leaving things out — and not by accident. Each thing it does not do is a deliberate trade with a real cost, and this post walks through them plainly, including where that cost makes Chirp the wrong choice.

One note on scope: this compares Chirp to the typical OIDC provider — the default shape of the category — not to any one product. Competitors change their pricing and features; the shape of the choices below is what's durable.

A spare surface, not a catalog

The usual provider offers openid, profile, email, often phone and more, plus a consent screen to mediate them. Chirp's identity surface is spare by comparison: a code response type, S256 PKCE, RS256 signing, pairwise subjects, and an openid scope that returns that subject and nothing else — no profile, no email claim, no roles. You can read the discovery document at /.well-known/openid-configuration in a few seconds.

The cost: Chirp will not hand your app a name, an avatar, a phone number, or a list of roles. If you want a display name, you ask the user for one. A provider that returns a rich profile saves you that form; Chirp doesn't, on purpose — every extra claim is data it would have to hold and hand out.

A different you at every app

The usual provider issues one global sub per user — the same identifier everywhere, typically sitting next to an email claim — so two apps, or two breached databases, can tell they share a user. Chirp issues pairwise subjects: a different, unrelated sub to each app, and no email claim at all, because there is no email scope to request.

The cost: there is no shared identifier two of your own products can join on, and signing a user in does not hand you their email address. If you rely on email to reach users or to reconcile one person across several properties, that becomes something you arrange deliberately, rather than get as a side effect of login.

No custom domains, no white-label

The usual provider lets paid tiers move auth onto your own domain (login.yourbrand.com) with your own theming. Chirp refuses this at any price: every user meets the same sign-in page on the same signin.chirpauth.com, with the same sender for magic links.

The cost: your brand is not on the sign-in page, and some teams will not accept that. The reason it is a refusal rather than a missing feature: one recognizable sign-in surface, identical for every app, is anti-phishing infrastructure. White-labeled auth trains users to type credentials on domains they have no way to recognize. (That argument is worth its own post.)

You can run it yourself

The usual provider is proprietary SaaS; if you leave, you re-implement auth. Chirp is AGPL-3.0 and self-hostable — Lambda, DynamoDB, and SES via Terraform in your own AWS account, running the same code as the hosted service.

The cost: self-hosting is your operations and your uptime. And the hosted option still asks you to trust the issuer with the root identities — pairwise subjects protect users from apps, not from whoever runs the issuer. The honest mitigation is not "trust us"; it is that the exit exists and runs the same code, so the party you trust can be you.

Two products, not one with modes

The usual provider is one product that accretes configuration — password, then MFA, then passwordless, toggled per tenant. Chirp ships two fixed modes: Zero (email magic-link) and One (passkey-only, with personas). An app integrates once and accepts both, and the modes never convert into each other.

The cost: you cannot flip a user from email to passkeys in place, or blend the two into a single knob-laden flow. The benefit is that each mode is a fixed, reasoned-about thing instead of a matrix of settings — and your app never has to care which one it is talking to.

Flat pricing, no meter

The usual provider charges per monthly active user, with overage billing — costs that scale with your success and spike when you least expect it. Chirp's model is flat, capped tiers: no per-active-user meter, no overage invoice. You pick a box; when you outgrow it you move to a larger box, not a surprise bill.

The cost: a cap is a ceiling. A very large deployment either sits on the top tier or self-hosts. What you do not get is a bill that grows with every sign-in.

The through-line

None of these are features withheld to upsell you later. They are a smaller surface chosen on purpose. The cost is real, and worth restating without softening: you collect your own profile data, your brand is not on the sign-in page, you cannot mix the two modes, and there are no knobs for the cases Chirp decided not to serve.

In exchange you get a provider small enough to read end to end, licensed so you can leave, and built so the identifier it hands out is not a cross-app tracking key.

If what you want is one dashboard that does identity, profiles, roles, billing, and B2B SSO with your logo on the login box, that is a real need and Chirp is the wrong tool — a maximalist provider will serve you better. Chirp is for the other case: where the smallest correct thing, that you could host yourself, is worth more than the longest feature list.