FIG. 00 · OAuth for AI agents & the enterprise

The OAuth service
for AI agents.

MCP and A2A authorization, sender-constrained agent tokens, and the full enterprise identity stack (OIDC, SAML, SCIM, Verifiable Credentials) on one standards-native platform. Auth, by people who read the RFCs. Priced flat, portable by design.

Start free Read the field guide
$ npx oauth-work init --tenant acme
agent→ authorize→ token→ MCP tool OAuth 2.1 · DPoP · scoped consent

The incumbents charge per connection.
We don't.

Flat pricing that doesn't punish you for growing. Bring your own keys, export everything, leave whenever. The standards are portable by design, and so are you.

See the pricing →

FIG. 01 · Agent authorization · MCP + A2A

OAuth that agents can actually use.

MCP, A2A, and on-behalf-of delegation: real OAuth 2.1 flows, sender-constrained tokens, and consent, built for autonomous clients.

FIG. 01a
MCP authorization
fam. Model Context Protocol

Real OAuth for MCP servers and clients: scoped tokens, consent, and discovery, so an agent connects to a tool the way the spec intends.

FIG. 01b
A2A delegation
fam. agent-to-agent

Agent-to-agent authorization: issue and verify delegated, on-behalf-of tokens between agents, each scoped to exactly what it may do.

FIG. 01c
Agent tokens
fam. sender-constrained · DPoP

Short-lived, sender-constrained (DPoP) tokens scoped per agent. A stolen agent token is inert, and every call lands on the audit trail.

FIG. 01d · on-behalf-of delegation chain · A2A + MCP
FIG. 02 · Protocol catalogue · plates 02a–02f

Catalogued and shipping.

A field guide to the enterprise stack: every protocol your buyers require, implemented to spec and in production today.

FIG. 02a
OIDC + OAuth 2.1
fam. OpenID · auth-code + PKCE

Full OpenID Connect provider with discovery, JWKS, and the OAuth 2.1 authorization-code + PKCE flow. Single-use auth codes, atomic by construction.

FIG. 02b
SAML 2.0
fam. XML-DSig · WebCrypto-verified

XML-DSig verified from scratch on WebCrypto. Signature wrapping and tampering rejected, cross-checked against xml-crypto in tests.

FIG. 02c
SCIM 2.0
fam. provisioning · users + groups

Standards-compliant user and group provisioning. Directory sync that doesn't drift.

FIG. 02d
DPoP · RFC 9449
fam. sender-constraint

Sender-constrained access tokens. Bound to the client's key, so a stolen token is inert.

FIG. 02e
WebAuthn
fam. passkey · packed attestation

Passkeys with verified packed attestation. Phishing-resistant by construction, per the WebAuthn Level 2 spec.

FIG. 02f
Verifiable Credentials
fam. W3C VC · VC-JWT / SD-JWT

A W3C VC rail: VC-JWT and SD-JWT, with Bitstring Status List revocation. Flip the bit, the credential reads revoked.

FIG. 03 · Sender-constrained tokens · RFC 9449

Tokens that can't be
replayed. By design.

  • Sender-boundDPoP binds every access token to the client that requested it. RFC 9449.
  • ReuseRefresh-token reuse is detected and the whole family is revoked. RFC 9700.
  • AttestationWebAuthn packed attestation statements are verified against the authenticator's certificate chain.
  • AuditEvery event signed and recorded: a clean trail for the people who answer to auditors.
FIG. 03a · sender-constrained access token · RFC 9449
FIG. 04 · Tenant isolation · did:web

Your tenants. Your keys.

Each tenant gets its own Ed25519 signing key, its own OIDC discovery and JWKS, and its own did:web:<slug>.oauth.work issuer. Tenant resolution is by host. Isolation is cryptographic: a separate key, a separate JWKS, a separate issuer.

acme.oauth.work
  • keyEd25519 · org-scoped
  • jwks/.well-known/jwks.json
  • issuerdid:web:acme.oauth.work
globex.oauth.work
  • keyEd25519 · org-scoped
  • jwks/.well-known/jwks.json
  • issuerdid:web:globex.oauth.work
initech.oauth.work
  • keyEd25519 · org-scoped
  • jwks/.well-known/jwks.json
  • issuerdid:web:initech.oauth.work
FIG. 04a · per-tenant issuers · did:web + RFC 8414 discovery
FIG. 05 · Integration · OIDC + OAuth 2.1

Integrated before
your coffee's cold.

One command to provision a tenant, standards-compliant endpoints you already know how to call, and docs that read like reference. No SDK lock-in; it's just OIDC.

Read the field guide
authorize.httpGET
# Authorize a user
GET /authorize
  ?response_type=code
  &client_id=acme-web
  &code_challenge=<S256>
  &scope=openid
302 Found · /callback?code=… (single-use)
FIG. 05a · authorization request · OAuth 2.1 + PKCE

Read the spec.
Then read ours.

Start free, or browse the field guide first. Either way, no sales call.

Start free Read the field guide