Skip to main content
If your service already authenticates humans with OAuth and machines with API keys, AFAuth is additive, not a rip-and-replace. Your user table, your IdP, and your billing stay where they are. AFAuth adds the one thing they can’t: a first-class identity for the agent itself, so an AI agent can sign up and operate on its own behalf without impersonating a human or carrying a human’s delegated secret.
New to the “why”? Why AFAuth covers what breaks when agents reach services through OAuth delegation or shared API keys. This page is the how — adopting it next to what you already run.

​
The incremental path

1

Add AFAuth in optional mode

Stand up an AFAuth surface with attestation optional. It accepts un-linked agents while you ramp, verifies attestations when present, and leaves your existing OAuth and API-key paths untouched.
const server = defineService({
  baseUrl: "https://api.example.com",
  serviceDid: "did:web:api.example.com",
  // ...stores, recipients...
  attestation: "optional", // verify when present; accept un-linked agents while you ramp
});
2

Route by credential

One branch at your edge: AFAuth-signed requests carry Signature + Signature-Input headers. Route those to AFAuth verification and let everything else fall through to your existing middleware.
if (req.headers.has("signature-input")) {
  return handleAfauth(req);   // verify the agent signature
}
return existingAuth(req);     // your OAuth / API-key path, unchanged
3

Map accounts to your user model

An AFAuth account has a stable account_id. Store it next to your own user/org records. While the account is UNCLAIMED, it’s the agent acting alone; when a human claims it, the claim hands you a verified human identity (email, OIDC iss+sub) you can link to that person’s existing OAuth account — bridging the agent to the human who owns it.
4

Tighten to attested_only

Once agents are linking to humans, flip the default to attestation: "required" (unclaimed_mode: "attested_only"). Now a verified human stands behind every new signup, a human’s whole fleet of keys groups onto one account for quotas and bans, and you have real spam resistance — without ever provisioning an API key.

​
What maps to what

You haveKeep it forAdd AFAuth for
OAuth / OIDC for humansHuman login; the claim ceremony’s identity checkThe agent’s own identity, pre-claim
API keys for machinesExisting server-to-server integrationsAgents that self-serve without you minting a secret
A users / orgs tableBilling, ownershipLinking a claimed account_id to the human who owns it
AFAuth occupies the identity-and-authentication layer for agents and sits alongside these — it doesn’t ask you to move any of them.
Want humans to sign in, too? Once agents are signing up attested, you can add a Sign in with AFAuth button — the agent-first analogue of “Sign in with Google”. The human lands in the account their agent already created, keyed on the same (iss, sub_h). It sits beside your existing OAuth, not instead of it.

​
Where to next

Accept AFAuth on your service

Stand up the service surface.

Attestation modes

off, optional, required — and when to move.

Invite and claim

How a claim bridges an agent account to a human.

Why AFAuth

What delegation and shared keys can’t do.

Add Sign in with AFAuth

The agent-first “Sign in with Google” for your human users.