Get started

Threat lab

One runnable script demonstrates the resource-server defenses described in these docs. A single process acts as the Authority, the protected resource server, and the attacker. It owns the signing key, mints tokens, serves a JWKS, runs a FastAPI application protected by auth51-verifier, and submits each attack to confirm that the verifier produces the expected result.

Run it

# in the auth51-verifier repo
python -m venv .venv && . .venv/bin/activate
pip install -e . -r examples/threat-lab/requirements.txt
python examples/threat-lab/lab.py

A ✓ means that an attack was blocked or that the legitimate baseline request was allowed. A ✗ means that the expected defense failed. The process exits with a non-zero status if any check fails, so the lab also serves as a conformance test.

What it demonstrates

#	Attack	Defense that stops it
—	Legit call: valid token + valid DPoP	Allowed (the baseline)
1	Steal a token and replay it without proof	Proof-of-possession: a cnf-bound token requires a DPoP proof (RFC 9449); copying the token does not provide the key
2	Forge a DPoP proof with the attacker’s key	The proof key must equal the token’s cnf.jkt (thumbprint mismatch)
3	Request with an inflated scope	The token must carry the scope required by the endpoint
4	Wrong operation (O6): use a GET token on DELETE	Each endpoint derives its own a51:rs scope. A GET token lacks the DELETE scope, while a correctly scoped DELETE token is allowed
5	Replay a DPoP proof on a different request	htu binds the proof to this exact URL
6	Present an expired token	The exp claim, including the permitted clock skew
7	Forge a token with the attacker’s signing key	JWKS signature verification
8	Use a token at the wrong resource server	aud (audience)
9	Tamper the agent’s prompt or code	The identity checksum changes, so the Authority won’t mint under the registered identity

The verifier blocks attacks 1–8 at the resource server level without calling the Authority. Attack 9 exercises the token minting-side identity check: agent identity is derived from the agent rather than from a stored secret, so tampering changes the checksum before a token is issued.

Note

The lab installs its public key in the verifier’s JWKS cache because it acts as the Authority for the test. The unmodified verifier checks the signature, DPoP proof, scope, audience, and expiry; the security checks are not stubbed. Replacing the local mint with a token from authority.auth51.com exercises the same verifier path.

Keep reading