FAQ

How is this different from 2FA?

Shortest version: 2FA is authentication; HumanAuth is authorization. 2FA proves who you are at login. Authorization decides whether an action may happen — and where classic authorization is rules deciding (roles, OAuth scopes), HumanAuth is a human deciding, per action, with cryptographic proof. It’s in the name.

2FA proves who’s at the door. HumanAuth proves a human approved what happened inside — and hands you the signed receipt.

	2FA / MFA	HumanAuth
Question answered	”Is this really you?” — at login	”Did a human approve this exact action?” — at action time
When it fires	Once, at session start	Per risky action, however old the session
Who’s involved	The person logging in	Possibly different people than the actor — the agent acts, the CFO approves, 2-of-3 for the big stuff
What it protects	Account access	The specific transaction — amount, payee, repo, instance
What it leaves behind	A login log line	An independently verifiable signed receipt bound to what was approved
Failure mode it stops	Stolen credentials	An authorized actor doing an unauthorized thing

The part that matters in the agent era: 2FA cannot apply to an AI agent. The agent isn’t an impostor — it holds valid credentials and passes every auth check you have. The risk isn’t a stolen key; it’s the legitimate key-holder doing something no human wanted. That is the question per-action approval answers.

Isn’t that just step-up authentication?

Step-up / transaction confirmation (3-D Secure, PSD2 SCA) is the closest relative — HumanAuth is that idea generalized and made portable. Three differences: step-up re-authenticates the same user in the same session, while HumanAuth routes asynchronously to other humans, with quorum and veto; step-up’s evidence lives inside the one system that ran it, while a HumanAuth receipt is verifiable by anyone, offline, without trusting us; and step-up is bolted into specific rails, while this is one API for any action in any system. The mechanics are the two classic factors — possession (device-held key) and inherence (biometric) — moved from the login screen to the moment of consequence, with SCA-style dynamic linking to the exact content.

Why not just do approvals in Slack?

Because a Slack approval is a chat message and a database write, and neither survives cross-examination. Run it forward six months, to the audit:

• Who clicked? Anyone with the channel open. Slack doesn’t know whether it was the CFO or whoever had her laptop unlocked.
• What did they approve? Whatever the message said. What the code did next is a separate write, made by the same systems the approval was supposed to check.
• Can the record change? Yes — it lives in your database, editable by your own admins. Your evidence depends on the integrity of the thing being audited.
• Does approval actually gate execution? Only by convention. Nothing stops a code path from skipping the check.

A receipt closes each gap cryptographically. The click is a biometric-gated signature from a key that exists only on the approver’s device — so who is non-repudiable. The exact parameters are hash-bound into the receipt — so a swap after approval fails verification. The record can’t be edited, because neither you nor we can re-sign it. And execution is gated structurally, because your resource server refuses to act without a receipt that verifies and burns its single-use jti: no receipt, no action; one receipt, one action.

Build the Slack version and, when a regulator asks you to prove the CFO approved this exact wire, you have a screenshot. Build on receipts and you have a signature the regulator can check themselves.

How is this different from webhook human-in-the-loop tools?

Tools in that category solve delivery: get the question to a human, get the answer back over a webhook. HumanAuth solves delivery too — and then makes the answer provable. In a webhook flow, “approved” is a boolean in an HTTP response: your code trusts the callback, execution is gated by convention, and the audit trail is whatever you logged. A HumanAuth approval is a dual-signed receipt your resource server verifies offline and burns after one use — the approver’s device key signs the exact plan-hash-bound parameters, so the proof survives independently of us, of the delivery channel, and of your own logs. If a human clicking a button is all you need, several tools do it. If you will ever have to prove the human clicked — to an auditor, a regulator, or your own security team — the click has to be a signature.

Why is verification offline? Isn’t that less safe?

The opposite — an online “is this valid?” oracle would couple your enforcement to our uptime, tell us what you verify and when, and create a single spoofable endpoint. Offline verification is local cryptography against published keys, with replay closed by single-use jti inside a 10-minute expiry. Full treatment: Security Model → Why verification is offline.

Is the replay store part of HARP, or just a recommended best practice?

Part of the protocol — only the storage is yours. The final step of the verification chain, the atomic claim of (jti, idempotencyKey), is normative in the spec, and @humanauth/verifier won’t even construct without a replayStore — there is no flag to skip it. What you supply is the backing store (Redis, Postgres, SQLite, Workers KV, or in-memory for dev — adapters) and its topology, because verification is offline and HumanAuth never sees your enforcement path. The split: cryptography enforces “no receipt, no action”; the replay claim enforces “one receipt, one action.” Full rationale: Verifier SDK → Ownership.

Do denials produce receipts too?

Yes — a denial mints a full signed receipt (result: "denied") with the denier’s device co-signature. “Prove we blocked it” is first-class evidence. Expiry deliberately mints no receipt: nobody signed anything, and the proof of non-consent is the absence of a receipt plus the platform record and the request.expired webhook. Denial reasons never travel in receipts — only a reason_hash commitment does.

How many people can be required to approve one action?

Up to 10 (quorum values, and membership of unanimous groups) — a product ceiling, not a protocol one, chosen so receipts stay small enough to pass inline anywhere and the consensus view stays legible. Details: Security Model → Consensus size and receipt transport.

Who vouches for an approver’s identity?

Depends on who runs the platform, and the receipt’s iss claim tells you which applies. On the hosted platform, enrollment requires an IdP-verified sign-in — HumanAuth attests that hu_… is a verified person. On a self-hosted deployment in operator mode, the operator attests it: they mint single-use invite codes and hand them to the right people, the same trust they already exercise over every internal account system. Either way, the signing credential is the hardware-held device key — never an IdP token — and the identity regimes section has the full treatment.

Can I self-host?

Yes — the platform deploys into your own Cloudflare account, so approval data, keys, and receipts never leave infrastructure you control, and receipts stay verifiable with the public verifier either way. See the Self-Hosting Guide; self-hosting is licensed and supported under an Enterprise agreement.

Is a receipt a JWT? Can I use it as an access token?

It is JWT-shaped (compact JWS, iss/aud/jti/exp claims) but deliberately carries typ: humanauth-receipt+jws;v=2 — not JWT — so strict validators will never accept a receipt as a bearer token. It’s an attestation of a decision, not a credential, and it expires within 10 minutes of minting.

Convinced enough to try it?

• Getting started — tenant, approver, first biometric-signed receipt.
• Receipt Engine demo — watch three approvals and three attacks, in your browser, no account.
• Questions the FAQ didn’t answer? support@humanauth.ai — a human replies same-day.