Your customers already sign in with GitHub, Facebook, or Google. Sign in with username.md adds a fourth option: standards-based OIDC single sign-on backed by an identity your customers own — portable, cryptographically verifiable, and ready for their agents as well as their browsers.
The case your security and support teams will make for you.
Authorization Code + PKCE against a standard OpenID Connect issuer. It drops into any OIDC-compatible identity stack the same way your GitHub and Google buttons did — no proprietary SDK, no new vendor runtime in your critical path.
Every handle carries signed, verifiable claims — domain ownership, linked accounts — under the handle's own Ed25519 key. "Is this really them?" becomes a cryptographic check, not a support ticket.
You receive standard OIDC claims and resolve the rest from the handle's public, content-negotiated profile on demand. Less PII at rest on your side is a smaller breach surface and a shorter compliance story.
A GitHub or Facebook identity exists at the pleasure of that platform. A username.md handle belongs to your customer — suspended socials don't lock anyone out of your product.
Handles are machine-resolvable (did:web, agent handshake surfaces,
per-handle llms.txt). When your customers send agents to use your product,
the same identity that signed in can be verified programmatically.
Every federated sign-in you offer trims password resets and account-recovery load. This one also gives support a verifiable identity to check before they act on "I'm locked out" — see the use cases.
Built to be an afternoon for your engineers and a one-pager for your security review.
Tell us your app name, redirect URIs, and client type (public PKCE for SPAs and
native apps, confidential for server-side). We provision your client_id
against the live issuer login.username.md during onboarding — usually
within a business day.
Two paths: drop the dependency-free badge script on your sign-in page, or add the issuer to your existing OIDC configuration exactly like your other providers. Copy-paste gateway quickstarts for common edge platforms are in the integration guide.
Validate ID tokens against the published JWKS; discovery is standard
(/.well-known/openid-configuration). Platform API responses are additionally
signed end-to-end (RFC 9421, Ed25519) — your auditors can verify what your systems
consumed. Worked examples live in the developer docs.
Volume identity resolution, bulk handle provisioning for your workforce or your fleet of agents, uptime SLAs, priority support, and a DPA are the Enterprise tier.
The issuer is live. Discovery is public — point your identity stack at it right now.
Hand this table to whoever owns your sign-in stack. Deeper detail: integration guide · developer docs.
| Question | Answer |
|---|---|
| Protocol | OpenID Connect — Authorization Code + PKCE (S256) |
| Issuer | https://login.username.md (live) |
| Discovery | /.well-known/openid-configuration — standard |
| Token validation | JWT ID tokens, verified against the published JWKS |
| Client types | Public (PKCE, no secret) and confidential (server-side) |
| Client registration | Provisioned during onboarding — email us your redirect URIs |
| The button | Drop-in badge script (no dependencies) or your own markup |
| Response signing | Platform API responses Ed25519-signed (RFC 9421) |
| At volume | Metered resolution, SLAs, DPA — Enterprise tier |
Send us your app name and redirect URIs and we'll come back with a provisioned client and a rollout checklist — usually within a business day.