DPoP verification for resource servers

Every client except a first-party web client receives bound tokens, so a real API sees them often. An unbound token arrives as Authorization: Bearer <token> and has no cnf.

All of these, in this order. The SDK's verifyDpopProof does them, and createResourceServer calls it for you.

Step 9 is the one an implementation most often gets wrong. A proof may be used once. Record each jti for at least as long as a proof can be accepted (two minutes covers the 60-second window either side) and refuse a repeat.

Identity's own endpoints require a server-issued nonce in the proof, and an operator can tighten the proof's iat window there below 60 seconds. A resource server does not have to. The SDK's resource-server verifier does not demand one, so a client talking to your API need not have a nonce from you. If you add one, answer a proof without it with 401 and a DPoP-Nonce header, as RFC 9449 describes.

A refusal is 401 with a challenge in WWW-Authenticate that names the algorithms you accept, and a body that does not say which check failed.

HTTP/1.1 401 UnauthorizedWWW-Authenticate: DPoP algs="EdDSA ES256", error="invalid_dpop_proof"Content-Type: application/json{"error":"invalid_dpop_proof"}

Use invalid_token when the access token itself failed, and invalid_dpop_proof when the proof did. When the token and proof are fine but the sign-in is too old or too weak, the SDK's requireAuthentication answers insufficient_user_authentication instead (Access token). A request with no credentials gets the challenge without an error. An API that also allows unbound tokens adds a Bearer challenge. Never echo the token, the proof or the reason.

The store holds the jti values you have seen. The SDK's in-memory store keeps 50,000 entries for two minutes and is per instance. That is correct for a single process and not for several: a proof captured at one instance could be replayed once at another inside its window. If your API runs on several instances, or on a platform where each request may reach a new one, implement the store over shared storage. Put a rate limit in front of the API either way, because a full store refuses new proofs rather than dropping a live one. See Protect your API.

import { ResourceServerError, createMemoryDpopReplayStore, createResourceServer } from '@tdacorp/identity-sdk'const resourceServer = createResourceServer({  issuer: 'https://identity.tdacorp.in',  audience: 'https://api.example.com',  publicOrigin: 'https://api.example.com',  replay: createMemoryDpopReplayStore(),})export async function GET(request: Request): Promise<Response> {  try {    const token = await resourceServer.verifyRequest(request)    return Response.json({ sub: token.subject })  } catch (error) {    if (error instanceof ResourceServerError) return error.response()    throw error  }}

The SDK is the package @tdacorp/identity-sdk on the public npm registry; see SDK.

• Do not accept a bound token as a bearer token. That removes the whole protection.
• Do not verify htu against the Host header. Use your configured public origin.
• Check ath and jkt both. One ties the proof to the token, the other to the key.
• Refuse a proof signed with none or an algorithm outside your list. The SDK's proof check accepts only EdDSA and ES256.
• Do not log proofs. They are valid for a short time and a replayed one is a stolen request.

• DPoP
• Access token
• Resource-server verification