Identity, sign-in, and session evidence
Sign-in that leaves a record you can prove.
CapchaID is CapchaCloud's identity product: email and password, magic links, email one-time codes, authenticator 2FA, social sign-in, signed JWTs for your own API, and session management — with a managed human-verification challenge in front of the credential routes and no separate bot vendor to buy. Every new account mints a tamper-evident consent certificate, and auth events are sealed into the same evidence chain that backs consent records and signature seals.
1 credit per auth session (≈ $0.005) — the cheapest action in the catalog, and the unit every other CapchaCloud price is pegged to. Free plan includes 500 credits a month, no card. See pricing.
Session evidence
The problem: your auth log is a row in your own database
Every auth vendor can tell you a user signed in. None of them give you a record of that sign-in that survives an argument. When a customer disputes an action, when an auditor asks who approved a change, or when a fraud claim lands months later, the answer is a row in a table you control — editable by you, and worth exactly as much as the other side's willingness to take your word for it.
There is a second problem underneath it. Most teams bolt an auth product onto a consent vendor and then drop a CAPTCHA in front of both: three contracts, three dashboards, three sets of secrets, for one job — let the right humans in and remember what they agreed to. CapchaID does that job on one tenant and one bill, and captures the authentication event as evidence at the moment it happens: hashed, stored under its own hash, and linked into an append-only audit chain — the same substrate every other CapchaCloud evidence surface uses, not a logging feature bolted on.
How it works
- Drop in the widget, or call the API. A one-tag install renders sign-in and sign-up in your page, or you call the auth routes directly from your own UI and keep your own front end.
- A human check runs before any credential is accepted. Sign-up and sign-in both require a managed human-verification challenge, with no keys for you to buy and no add-on to enable. It fails closed by design: if the verification secret is missing, those routes refuse the request rather than quietly letting traffic through, and a sandbox always-pass key is rejected in production.
- Signup mints a consent certificate. A new account seals what the person agreed to — the event, the application, the network origin, the edge geolocation, the user agent, the timestamp, and which human-check methods actually verified — into a certificate with its own id. Signups that ran no interactive challenge (a provisioning API, for example) record no methods passed rather than a fabricated pass.
- The session is created and one credit is drawn. The credit is charged inside session creation, before the session exists — so a failed sign-in never costs a credit, and an exhausted balance returns
402instead of issuing a session you cannot account for. - The auth event is sealed and anyone can check it. The sealed payload is hashed with SHA-256, written to the evidence vault under that hash, and folded into the append-only audit chain. A public endpoint returns the event type, seal time, vault hash, chain hash, and chain-inclusion status to anyone holding the certificate id — while withholding IP, geolocation, and user agent from anonymous callers.
What's actually in the product
Per-capability status, no rounding up. Live means enabled and answering requests
today — the flags are published for you to check at
/api/v1/public-config and /api/v1/auth/providers.
Config-gated means the code is written and routed but stays off until
credentials are supplied. Not sold yet means we will not put a checkmark next to it.
Email and password
Passwords are stored as PBKDF2-HMAC-SHA-256 derivations over a random per-user salt, verified in constant time, with a minimum-length policy enforced at sign-up. Password reset invalidates every existing session.
Magic links
A single-use sign-in link with a 15-minute lifetime. The destination is bound at the moment the link is requested, rather than read from a callbackURL parameter the recipient could edit — so a forwarded link cannot be turned into a redirect somewhere else.
Email one-time codes
Six-digit codes with a five-minute lifetime, single-use, throttled on both the send and the verify side so a six-digit code space cannot simply be walked.
Authenticator 2FA
Standard TOTP — six digits, 30-second period, one-step drift window — plus ten single-use backup codes. Enrollment fails closed rather than writing a secret in the clear when the encryption key is unset, and verify attempts are throttled so the 2FA step cannot be brute-forced by someone who already has the password.
Google sign-in
OAuth with PKCE (S256) and HMAC-signed, single-use state that fails closed without its secret. Google is the provider configured in production today; the authoritative live list is /api/v1/auth/providers.
Sessions you can actually revoke
Thirty-day sessions in an HttpOnly cookie. The raw token is never stored — only its SHA-256 digest is kept at rest. List active devices, revoke one, revoke all, or revoke everything except the one you're on.
Signed JWTs for your own API
Short-lived access tokens with a published JWKS endpoint and a tenant-scoped audience, so your backend verifies against a public key instead of calling us on the hot path. Private signing keys fail closed rather than persist unencrypted.
Bot screening, nothing to buy
A managed human-verification challenge is wired into the credential routes with no separate vendor contract, no add-on, and no keys for you to manage. Production runs a real key — the always-pass sandbox key is explicitly refused.
Rate limiting that means it
Credential-guessing routes are throttled on two independent buckets at once — per source address and per identity — because per-IP alone loses to a botnet and per-identity alone loses to one host spraying many accounts. Sign-in, one-time-code send and verify, and 2FA verify are all covered.
Managed auth email
Magic links, one-time codes, and password-reset mail send from CapchaCloud's own managed domain out of the box — no customer DNS, no domain warm-up, no separate email vendor to contract. Delivery failures surface loudly rather than being swallowed.
More social providers
Microsoft, GitHub, Apple, Facebook, and LinkedIn are implemented — including Apple's ES256 client-secret assertion — and each returns a not-configured error until its credentials are supplied. Additional providers are on the roadmap, not offered as a live promise today.
Organizations and SCIM
Organization membership with owner / admin / member roles, invitations, and active-organization switching that flows into the token. SCIM 2.0 user provisioning is implemented and gated behind a per-application token; SCIM groups are not. Multi-user workspaces are in development — see the roadmap.
Passkeys and enterprise SSO
Passkeys / WebAuthn are reserved and not sold today. SAML single sign-on is in development: configuration can be stored, but a login is not completed until an identity provider has been validated end to end, so it stays off by default. We would rather say that than sell a checkmark.
What the sealed auth-evidence record contains
A session proof is written whenever a session is created. An auth-evidence certificate is the sealed, third-party-checkable form of a specific auth event, and it carries the fields below.
| Field | What it holds |
|---|---|
| event | One of login_success, session_created, session_revoked, totp_verified. Anything else is rejected outright. |
| owner_account_id | The CapchaCloud tenant the event belongs to — checked against real tenants before anything is sealed, so an upstream bug cannot write a phantom or cross-tenant record into permanent storage. |
| application_id / app_user_id | Which of your applications, and which end user inside it. |
| ip | The network origin observed server-side at the edge — not a value the browser can assert. |
| geo | Edge geolocation signals derived from that network origin. A network-origin estimate, never device GPS. |
| user_agent | The submitted user-agent string, truncated to 512 characters. |
| timestamp / sealed_at | The event time and the moment the record was sealed. |
| vault_hash | SHA-256 of the exact sealed bytes. The record is stored under its own hash, so the storage key is the integrity check. |
| chain_hash | The append-only audit-chain entry the seal was folded into. |
| anchored | Honest, not decorative. If the chain write fails, this comes back false and the response is a 207 — no chain_hash is fabricated to make the record look better than it is. |
| certificate_id | An authev_ identifier you can hand to a counterparty, an auditor, or opposing counsel. |
The public read endpoint returns the event, seal time, vault hash, chain hash, chain-inclusion status, and a link to a signed evidence bundle. It does not return IP, geolocation, or user agent to an anonymous caller — those stay inside the sealed payload, reachable only by whoever holds tenant access.
Don't take our word for it
A sealed auth event is readable by anyone holding its certificate id, and the signed bundle it points at can be checked offline with a dependency-free verifier that makes no network calls back to CapchaCloud. Blocks in the evidence chain are independently timestamped under RFC 3161 and anchored asynchronously to Bitcoin via OpenTimestamps; live anchoring status is published.
curl -s https://capchacloud.com/api/v1/auth-evidence/authev_<uuid> curl -O https://capchacloud.com/verify-evidence-bundle.mjs curl -o bundle.json "https://capchacloud.com/api/v1/public/evidence-bundle/authev_<uuid>" node verify-evidence-bundle.mjs bundle.json
Live chain tip and anchor status: /api/v1/transparency · Method in full: evidence methodology · Algorithms and parameters: cryptographic inventory.
Integration
The browser side is one tag. The publishable key is safe in client code; never put a secret key
there. A sandbox key renders on any origin including localhost, so
your first paste works; a live key renders only on origins you have allow-listed.
<script src="https://capchacloud.com/install.js"
async
data-capcha-client-id="YOUR_PUBLISHABLE_KEY"
data-capcha-mount="body"></script>
Prefer to place the component yourself? The two-line form mounts a custom element wherever you put it:
<script src="https://capchacloud.com/widget.js" async data-capcha-widget></script> <capcha-auth data-capcha-client-id="YOUR_PUBLISHABLE_KEY"></capcha-auth>
Server-side, verify CapchaID's JWTs against the published JWKS — no call to us on the hot path.
Webhooks push user.created,
session.created, and session.ended to
your endpoint, signed with HMAC-SHA256 over "{timestamp}.{rawBody}",
with delivery logs and replay. Writes accept an
Idempotency-Key header so a network retry never double-applies.
GET https://capchacloud.com/api/auth/jwks # verify access tokens offline GET https://capchacloud.com/api/auth/token # short-lived, tenant-scoped audience
Full contract: API reference · agent-readable integration guide · MCP tools, if you would rather have an agent wire it up.
Pricing
Priced in credits, not per seat. Credits come from your plan and pool across every CapchaCloud product — one subscription, one bill. Plan credits are spent first; prepaid pack credits never expire and are spent only after that. Nothing is metered and invoiced after the fact.
Auth session
Free plan
Bot screening and 5-year evidence retention are included on every plan, not sold as add-ons. Auth-session credit metering is live in production today — it is the action every other price in the catalog is pegged to. Full catalog: pricing.
What this does not prove
Every signed evidence bundle CapchaCloud emits carries its own
does_not_prove list, in the record itself, not just on a web page.
Here is what an auth-evidence record does not establish:
- Not who was at the keyboard. A sealed sign-in proves that these credentials, from this network origin, produced a session at this time. It does not prove the account holder was the person authenticating. Nothing in CapchaID performs identity-document or biometric verification — that is CapchaVerify for screening evidence, or CapchaShield when you need a licensed vendor's certified verification.
- Not physical location. Edge geolocation is a network-origin estimate, city-level at best and relocatable by a VPN or proxy. It is never device GPS, and the record labels its own provenance and precision so it cannot be read as more than it is.
- Not that the underlying facts are true. The record proves that these bytes and their position in the tamper-evident chain are exactly as stated — not that an identity claim, a consent context, or a document's contents are true in the world.
- Not legal compliance or admissibility by itself. It is one input to a compliance or legal determination, not the determination. Admissibility is always a court's call, and none of this is legal advice.
- Not a certification. CapchaCloud holds no SOC 2, ISO 27001, HIPAA, PCI, or equivalent attestation on any product today. A SOC 2 Type I engagement is listed as planned, not started on the public roadmap. Nothing here should be read as a certification claim.
- Not chain inclusion until it is. When a record has not yet been folded into a signed block, the chain-inclusion status comes back pending or absent. That status is reported honestly and never fabricated as included.
- Tamper-evident, not tamper-proof. The chain makes alteration detectable. It does not make alteration impossible, and we do not describe a hash chain as operator-proof storage hardware.
Questions
What exactly costs a credit?
One credit per session created. Sign-up, sign-in, magic-link verification, one-time-code sign-in, and OAuth callback each mint a session, so each costs one credit. Refreshing a page, calling your own API with a valid session, or failing a sign-in costs nothing — the charge happens inside session creation, past every validation gate.
Which social providers can I turn on today?
Google is configured in production. Microsoft, GitHub, Apple, Facebook, and LinkedIn are implemented and activate when credentials are supplied; more providers are on the roadmap. The authoritative live list is GET /api/v1/auth/providers — check it rather than trusting a marketing page.
Can I bring enterprise SSO?
SCIM 2.0 user provisioning is implemented. SAML sign-in is in development: configuration can be stored, but it stays disabled per application until an identity provider has been validated end to end. Track it on the roadmap.
Do my users need my DNS configured for auth email?
No. Magic links, one-time codes, and password-reset mail send from CapchaCloud's own managed domain out of the box — no records to publish, no domain to warm up, no separate email vendor to contract.
How is this different from just adding a CAPTCHA to my auth?
A CAPTCHA gives you a pass/fail in the moment and nothing afterwards. CapchaID records which human-check methods actually verified as part of the sealed record — and when no interactive challenge ran, it seals that fact instead of a fabricated pass. That distinction is the difference between a screening step and evidence.
Where does this run, and where is the evidence stored?
Authentication executes at the network edge, close to the user, rather than in a single application region. Where evidence objects live, and which storage regions are used by default, is documented on data residency; third-party roles are listed in the subprocessors policy.
How does this compare to Clerk?
Side by side, including where Clerk is the better pick: CapchaID vs Clerk.
Ship auth, keep the evidence
500 credits a month on the free plan, no card. Add one tag, or call the API directly.
Related
CapchaID vs Clerk · CapchaConsent · Pricing · Evidence methodology · Trust Center · Roadmap