Private Access Tokens

Private Access Tokens (PATs) let a client prove that it passed a device attestation without revealing identifying device information to the origin. A PAT is a client challenge mechanism, not an Edge Admin API token.

This feature was first introduced in OpenResty Edge 26.9.1-1.

# Configure trusted issuers

Open Global Config > PAT Issuers. Reading the list requires the corresponding read permission; changing it requires write permission.

Each issuer has:

• Name: a unique administrative name.
• Directory URL: the issuer’s full HTTPS directory URL.
• Enabled: whether gateway nodes trust and advertise the issuer.

For the directory URL, use the complete well-known path that the issuer specifies.

A disabled issuer stays in the configuration but is neither trusted nor advertised. Deleting one removes it from gateway trust once configuration synchronization completes.

# Use PAT as a WAF action

In an application’s WAF rule, select Private Access Token as the block action, then choose the fallback for clients that cannot present a valid token: Edge CAPTCHA, hCaptcha, JavaScript Challenge, or Page Template.

Clearance Time is a positive number of seconds that controls how long a successful client goes without repeating the challenge, and defaults to 60. Changing an application rule requires that application’s write permission, which is independent of PAT issuer permission.

# Use PAT in limiting actions

Limit request rate, block requests, limit request count, and limit request concurrency also support Private Access Token as the reject action. They use the same fallback and clearance rules; as with any other page rule, the change reaches gateway traffic only after you release it.

# Fallback templates

# Runtime behavior

A valid attestation grants clearance for the configured period. Everything else falls through to the fallback: an invalid token, a client with no PAT support, or an issuer that is disabled, deleted, or unreachable. That makes the fallback as important to availability as the issuer itself.

Choose a fallback that legitimate clients can complete, and test the rule with both a PAT-capable client and an ordinary browser before releasing it broadly.

# Operational notes

Note that whether a client passes PAT verification rather than taking the fallback is up to the client: even a PAT-capable client may skip verification and go straight to the fallback.