Privacy Pass tokens explained: roles, flow and proxies

Privacy Pass tokens let a client prove it passed a check without saying who it is. How issuance and redemption work, where tokens run, what proxies change.

Guidesby 11 min read
The client, a phone headed Privacy Pass, holds three cached one-time tokens, signed blind, in front of a sky glass sheet. Back left, the issuance deck after one check: the attester knows who, the issuer signs blind, tied to the phone. Back right, the redemption deck, later: the origin learns only that the client is verified. One token lifts off the phone as a gold sheet, Authorization: PrivateToken, and rises to the origin. Each deck sends a dashed link toward the other that stops short of a red card between them: no link, the token cannot tie issue to redeem. Under the origin a card: it still sees the client or proxy exit IP, 192.0.2.140.
Quick summary · TL;DR
  1. Privacy Pass tokens prove a check without an identity. A client passes attestation once, an issuer blind-signs tokens, and a website later verifies one and learns only that the client was verified.
  2. Four roles keep the data apart. The attester knows the client, the issuer signs without seeing the token, and the origin sees only a valid token, so the token gives no party a link from identity to destination.
  3. Private Access Tokens are Apple's deployment. iOS 16 and macOS Ventura or later devices fetch type 2 Blind RSA tokens, with Apple as attester and Cloudflare and Fastly as issuers.
  4. A token never replaces the IP signal. The origin still sees the client or proxy exit IP, and a redemption context can tie cached tokens to one network.

Privacy Pass tokens are cryptographic passes that let a browser or app prove it passed a check, such as a solved challenge or a device in good standing, without saying who it is. An attester vouches for the client, an issuer signs a blinded token, and the website checks the token and learns only that the client was verified.

The question usually starts with something odd in a network log. A request to a /cdn-cgi/challenge-platform/.../pat/... path returns 401, or a response carries WWW-Authenticate: PrivateToken. Is that a block? Does the IP address matter? What happens when traffic leaves through a VPN or a proxy?

The answers sit in three IETF documents published in June 2024 and in the deployment notes of the companies that run them. The same documents show that the origin still scores the IP next to any token, and that no token exists until an attester vouches for the client.

What Privacy Pass tokens are

Privacy Pass is an authorization protocol. A client gets tokens after one check and redeems them later, and the two events cannot be linked. RFC 9576, the Privacy Pass architecture (June 2024), describes tokens that prove nothing beyond the fact that a given issuer created them for a client that passed attestation.

It started with shared IPs. RFC 9576 names the motivating case: traffic from services such as Tor, where good and abusive clients share exit addresses. Cloudflare announced support in 2017, and its Privacy Pass reference (checked October 1, 2026) still frames the value the same way: visitors from shared networks, VPNs and Tor tend to have poorer IP reputation, and a token lets a good client prove itself anyway. The same problem exists on carrier networks, where CGNAT puts many subscribers behind one address.

Unlinkable is the whole point. The issuer signs a token it cannot see. When the client spends it, the token itself gives neither the issuer nor the website a way to match the redemption to the moment of issuance, even if they compare notes. From the token, a website learns “verified”, nothing more. Timing, the IP address and other request metadata are separate channels the token does not hide.

The four roles

Every deployment splits the work across four parties so that no single one knows both who the client is and where it goes.

  • Client. The browser, app or operating system that asks for tokens and spends them.
  • Origin. The website or API that sends a challenge and verifies the token.
  • Attester. Runs the check: a solved challenge, a device integrity check, a valid account.
  • Issuer. Signs blinded token requests for clients the attester approved.

Cloudflare’s deployment notes (checked October 1, 2026) spell out the split. The attester knows who the client is but not the origin. The issuer knows a client was attested and is owed a token. The origin knows only that the client is verified.

Roles can be combined. A joint attester-issuer model fits a company that verifies its own accounts and signs the tokens. Apple’s deployment is fully split: Apple attests, Cloudflare and Fastly issue, and the website verifies.

How do Privacy Pass tokens work?

The exchange runs on a standard HTTP authentication scheme, defined in RFC 9577 (June 2024). The origin answers a request with 401 and a challenge. The client fetches a token if it has none cached, then repeats the request with the token attached.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: PrivateToken challenge="BASE64URL_CHALLENGE", token-key="BASE64URL_ISSUER_KEY", max-age="10"

GET /resource HTTP/1.1
Host: origin.example
Authorization: PrivateToken token="BASE64URL_TOKEN"

The challenge. The challenge parameter carries a TokenChallenge structure with four fields: token_type, issuer_name (which issuer the origin trusts), redemption_context (empty or 32 bytes the origin chooses) and origin_info (empty, or the origin names the token may be spent at). token-key carries the issuer’s public key, and the optional max-age says how many seconds the challenge stays valid.

Issuance. The client completes attestation, then sends the issuer a blinded token request. The issuer signs it without seeing the token, and the client unblinds the result. RFC 9578 (June 2024) defines how.

Redemption. The client sends Authorization: PrivateToken token="..." and the origin verifies the signature. Each token carries a unique nonce, and origins should keep double-spend state so the same token cannot be redeemed twice.

Try the flow locally

Cloudflare’s getting started page (checked October 1, 2026) gives two ways to watch a real exchange. Its browser demo tool fetches the demo issuer directory at demo-pat.issuer.cloudflare.com/.well-known/private-token-issuer-directory, builds a challenge, and returns a finalized PrivateToken token=... value. The open source privacypass-ts library runs issuance and redemption in one Node.js process with real Blind RSA and a stubbed attester. Production issuers accept token requests only from an authenticated attester, and a live site accepts only tokens from the issuers named in its own challenge.

Token types

RFC 9578 registers two issuance protocols. Type 0x0001 uses a VOPRF over P-384 with SHA-384, and only the issuer’s private key can verify the token, so the origin either is the issuer or asks it. Type 0x0002 uses 2048-bit Blind RSA, and anyone with the issuer’s public key can verify. Apple devices request type 2, and Cloudflare’s issuers sign it, according to Cloudflare’s protocol page (checked October 1, 2026).

Per-origin and cross-origin tokens

An empty origin_info makes a token spendable at any origin that trusts the same issuer. That helps caching. It also opens two attacks RFC 9577 describes, reflection (an attacker relays an origin’s challenge to a victim and spends the resulting token) and exhaustion (one origin drains a client’s cross-origin tokens). Binding tokens to named origins, or to a fresh redemption context, closes both.

Private Access Tokens on Apple devices

Private Access Tokens are Apple’s deployment of Privacy Pass. Per Apple’s developer challenge page (2022, checked October 1, 2026), devices on iOS 16 and macOS Ventura or later support token type 2, with Cloudflare and Fastly as the test issuers. Apple acts as attester and checks the device and the Apple account. It never learns which site asked for the token.

So the difference between Privacy Pass and Private Access Tokens is scope. Privacy Pass is the protocol and its three RFCs. Private Access Tokens are one deployment of it, with Apple as attester and a fixed set of issuers, built into Safari and the operating system.

Apple also tells site owners not to block page loads on a token. Clients that cannot produce one must still reach the site.

Where Privacy Pass runs today

Cloudflare challenges. A Private Access Token is one signal among several when a Challenge Page loads. Cloudflare’s Private Access Tokens reference (checked October 1, 2026) says two things. A valid token removes some challenge steps but does not skip the Challenge Page. And the 401 on the pat path is expected when a device, browser or network cannot provide a token, including “when connected through certain VPNs”. It does not mean the visitor is blocked.

Turnstile. Cloudflare’s Privacy Pass overview (checked October 1, 2026) lists tokens as one of the signals Turnstile uses to decide whether to show a challenge.

Privacy proxies. Tokens also authenticate people to proxies whose operator must not know who they are. Cloudflare’s Privacy Proxy authentication page (checked October 1, 2026) shows the token sent in Proxy-Authorization with the CONNECT request. Per Cloudflare’s Privacy Proxy overview (checked October 7, 2026), the same product serves as a second-hop relay for iCloud Private Relay and powers Microsoft Edge Secure Network.

Account and age attributes. The same overview describes attesters that vouch for a valid subscription or an age threshold, so a service can check the attribute without storing it against an identity. Cloudflare’s OHTTP Relay (formerly Privacy Gateway), which runs Oblivious HTTP, also uses tokens to authenticate clients.

The browser extension. Cloudflare’s Silk extension for Chrome and Firefox now implements the IETF version with publicly verifiable tokens, per its GitHub README (checked October 1, 2026). The original 2017 tokens are gone: Cloudflare stopped accepting them in September 2023 and removed the public API in March 2024.

What a token proves and does not

A Privacy Pass token carries close to one bit: an issuer the origin trusts signed it for a client that passed some check. It does not say who the client is, why it is visiting, or that the next request will behave.

The IP address stays visible. Privacy Pass hides the link between issuance and redemption. It does not hide the connection. The origin still sees the client IP, the TLS handshake and the request pattern, and scores them as before. RFC 9576 adds that without an anonymizing service, the client’s IP can split clients into smaller groups and weaken unlinkability.

Anonymity depends on crowd size. Tokens protect a client only while many clients look alike. More attestation types, rare issuers or per-client keys shrink that crowd, which is why the architecture warns against origins handing out client-specific issuer keys.

The attester is the gate. A token exists because Apple vouched for a device, or because a person solved a challenge, or because an account checked out. Automation without that attestation gets no token, and a site may still challenge a client that presents a valid one.

Rate limits and anonymous credentials

The 2024 RFCs give one-time tokens. Newer drafts in the working group add metering without identity.

Cloudflare’s overview lists these as the route to rate limiting without identifying users, with production use cases “still in development”. They show how sites plan to count and throttle agents and automated clients they cannot name.

What proxies change for Privacy Pass

A proxy changes the network path. Privacy Pass tokens live one layer up, in HTTP headers, so the two interact in specific places.

The token passes through a tunnel intact. Over HTTPS, a CONNECT or SOCKS5 proxy relays encrypted bytes and never sees the Authorization header. On proxymint’s residential and mobile gateways, HTTPS through CONNECT is a blind tunnel, and a measurement on 2026-09-28 found no Via or Forwarded header added toward the target (proxymint Lab #1, one package per tier, US exits). Only a middlebox that decrypts traffic and rewrites headers could damage a token on the way.

The origin sees the exit IP next to the token. The token adds a signal. The IP signal stays, and it now belongs to the exit. Whether that address is a home connection from rotating residential proxies, a carrier address or a datacenter range, the exit type shapes how the site scores the request beside any token. How websites detect proxies lists the address signals a site reads.

A network change can void cached tokens. RFC 9577 lets an origin bind the redemption context to the client’s network, for example a pseudorandom function of the client ASN, or of a time window. It also says clients should discard context-bound tokens after flushing cookies or changing networks without origin state. Where an origin binds tokens this way, a browser that rotates exits between requests can face a fresh token challenge after each change, and a sticky session keeps one network for the length of a task.

Some networks cannot fetch a token at all. Cloudflare names “certain VPNs” among the environments where the Private Access Token request fails with 401. The challenge then falls back to its standard form.

Where Privacy Pass tokens fit

A site owner who wants fewer challenges for real visitors on Apple devices requests Private Access Tokens from a trusted issuer, never blocks the page on a missing token, and binds tokens to the origin. The IP and behaviour checks already in place stay.

A team that runs browsers or HTTP clients through proxies for testing or monitoring can read the 401 on the pat path as “no token available” and move on. When the target binds tokens to a network, one exit for the length of a session avoids repeat challenges. Headless automation has no attester to vouch for it, so the IP signal carries the weight.

An operator of declared bots or AI agents needs a different tool. A signed request names the operator, while Privacy Pass tokens hide who sent the request; the rate-limit drafts are the Privacy Pass work that affects agents. For permitted work that needs a stable, consumer-origin IP, the types of proxies guide maps which category fits which job.

Frequently asked questions

Privacy Pass tokens are one-time cryptographic tokens that prove a client passed a check, such as a solved challenge or a device integrity test, without revealing who the client is. An issuer signs them blind, so the website that later verifies a token cannot use it to link back to the moment it was issued. The protocol is defined in RFC 9576, 9577 and 9578, published in June 2024.

A website answers a request with 401 and a WWW-Authenticate PrivateToken challenge naming the issuer it trusts. The client passes attestation, sends the issuer a blinded token request, unblinds the signed result and repeats the request with an Authorization PrivateToken header. The website verifies the signature and keeps double-spend state so each token is used once.

Privacy Pass is the IETF protocol. Private Access Tokens are Apple's deployment of it on iOS 16 and macOS Ventura or later, where Apple attests the device and account and Cloudflare and Fastly act as issuers. Every Private Access Token is a Privacy Pass token of type 2, publicly verifiable Blind RSA.

They reduce them. Cloudflare uses a Private Access Token as one signal on its Challenge Page, and a valid token removes some challenge steps, but the visitor still passes through the Challenge Page. Clients without a token fall back to the standard challenge.

Not through the token itself. Issuance and redemption are unlinkable, and the origin learns only that an issuer it trusts signed the token. The website still sees the client IP address, the TLS handshake and its own cookies, and RFC 9576 warns that small anonymity sets or client-specific issuer keys weaken the protection.

A token in an HTTP header passes through a CONNECT or SOCKS5 tunnel untouched, because the proxy only relays encrypted bytes. Fetching a token can fail on some networks: Cloudflare lists certain VPNs among environments where the Private Access Token request returns 401. And an origin can bind tokens to the client network, so tokens cached before an IP change may not be accepted after it.

The original 2017 extension tokens are retired: Cloudflare stopped accepting them as a challenge alternative in September 2023 and removed the public API in March 2024. Cloudflare's current Silk extension for Chrome and Firefox implements the IETF protocol with publicly verifiable tokens and is described as a research client.

Tags

Researched and drafted with AI tools, then checked against our publishing rules before it went live: 16 outside links, 6 links to other proxymint pages, no prices and a fact-check pass against our product records. How we write.