Private Access Tokens: A CAPTCHA-less future | Fastly

Earlier today at WWDC, Apple presented a demo of a new technology that allows users to leverage Fastly to seamlessly access content at FT.com with zero CAPTCHAs, all while respecting end-user privacy. At its core, Private Access Tokens present a privacy-respecting, anti-fraud and authorization framework. This blog post provides an overview of what it does and how developers can try it out with Fastly and Apple today.

Behind the scenes: community-driven, open, standardized tech

Fastly worked with our friends at Apple, Cloudflare, and Google to develop and standardize the technology behind Private Access Tokens. It is a more accessible and capable iteration of the Privacy Pass protocol. If you’re familiar with Chrome Trust Tokens, Private Access Tokens might seem familiar.

Private Access Tokens develop on the above technologies to build toward something that can be used more broadly (no browser plugin required) and can be configured to provide anonymity to end-users. An IETF working group is currently developing and standardizing this technology in the open. Best of all, website developers can try it out right now.

Solving UX, accessibility, and privacy problems

CAPTCHAs seem to be everywhere. Anyone who uses the web is painfully familiar with them. They provide useful anti-fraud protection for websites, but they also make the web less accessible: some users don’t care to solve them (and move on), while other users have difficulty solving CAPTCHAs altogether – and are prohibited from accessing content.

Likewise, privacy-minded folks have concerns about what is happening with the data they provide to solve CAPTCHAs. Are CAPTCHA solves and legacy authorization tokens being used to track us? Folks with privacy-oriented browsing configurations are given plenty of prompts to think about these questions – they often get challenged with even more CAPTCHAs than typical users.

Private Access Tokens are an alternative to CAPTCHAs for supported client platforms. They use careful application of cryptography and requirements to guarantee that a website learns only exactly what it needs to know about a user in order to provide access to a resource. Human interaction is not required and there is no leakage of non-essential data.

How it works: the cool parts

Private Access Tokens work similarly to other challenge/response authorization frameworks. You can read all about the architecture here. The parts that give it the cool features – eliminating human interactions and respecting privacy – boil down to a few clever ideas.

The first one is standing on the shoulders of existing authentications and identities. The architecture does this by specifying an external system that can attest to only the necessary information about the user. This is called the “attester” in the specification. The attester might have access to more data about the user – think of all the info accessible on your phone. But the attester is designed to use cryptographic means to attest to exactly – and only – the minimal information needed for interaction with the website.

The second clever idea is separation of duties – a common pattern in cryptographic designs like differential privacy and secure multi-party computation. In this case, Private Access Tokens specify that “clients” and “attesters” (e.g., your device and Apple) are the only ones that can access user data needed to say something useful about the client. “Origins” (e.g. websites) learn only that some valid client accesses their site. “Issuers” (e.g., websites and organizations that issue tokens) learn only that they issued a valid token to some client. 

Last but not least, Private Access Tokens carefully apply cryptographic designs to make this all work. Notably, they apply blinded signatures. In a nutshell, when your client platform attests to some property about you, it cryptographically blinds data about the website you’re visiting. It sends this data to a token issuer (who trusts the attester), who makes a blind signature over this data and returns it. That is, the issuer signs the data without knowing what it is (a terrible idea for a mortgage, but a fine one here : ).

Summary of flow for blind RSA (token type = 2). For more detail, check out the spec.

Failure checking and edge cases aside, the flow works like this:

1. A user (“client”) requests access to a protected resource on a website (“origin”). At this point, the website doesn’t need to know anything about the client, including its IP address if you’re using a VPN or iCloud Private Relay.

2. The website replies with a challenge for a Private Access Token via a “WWW-Authenticate” HTTP response header.

3. The client then blinds the challenge and includes it in a token-request message to a system (“attester”) that (1) can attest to the property the website cares about (like running on a verified iOS device) and (2) is trusted by the system that issues the token (“issuer”). 

4. The attester then forwards the request to the token issuer. The issuer checks the request and, if all looks good, blindly signs it and provides the result (within a “TokenResponse”). Note that the issuer doesn’t know anything about the client thanks to the cryptographic blinding done by the client.

5. The attester forwards the TokenResponse to the client, who finalizes the cryptographic process to produce the final signature over the blinded data (from step 3). This signature is used to create the token the origin expects.

6. The client provides this token to the origin (via an “Authorization” HTTP request header, for those familiar) and is granted access to the resource. At this point the website knows only that the client has a valid token – all of the information exchanged with the attester is still private to those parties.

When you put this together, no one entity can link client identity to website activity. And yet, this authorizes access to a website – all while eliminating human interactions. Pretty cool!

If you’re familiar with typical website tracking technology, you might think, “Well, the website will still track visitors by their IP address.” That’s true – but users have growing options to plug that data leakage as well, for example via privacy proxy services like Apple’s iCloud Private Relay (which utilizes Fastly’s Private Gateway service).

Try it out

Let’s put theory aside here. We’ve worked with our partners in the ecosystem to make the building blocks for Private Access Tokens available to developers today.

• Early access to a client and attester: If you want to get a head start with the Private Access Token features in the new Apple macOS and iOS releases, sign up for the Apple beta program.

• Enable Private Access Tokens for your site: Check out the specification documents for issuing a challenge and handling a token redemption. And stay tuned for more info on how Fastly Next-Gen WAF can make this easier for you.

• Issue a token: Fastly has deployed a live service for issuing tokens. See below for configuration details This endpoint supports any origin (and is for development only!). Try sending a well-formed issuance request (from a compatible iOS or macOS device) to it today and you’ll get back a valid token you can use to redeem on an enabled website.

Demo configuration

Issuer name

demo-issuer.private-access-tokens.fastly.com

Base64-encoded issuer public key:

MIICUjA9BgkqhkiG9w0BAQowMKANMAsGCWCGSAFlAwQCAqEaMBgGCSqGSIb3DQEBCDALBglghkgBZQMEAgKiAwIBMAOCAg8AMIICCgKCAgEAubzND7lvK-u5aIFHSt_NHIzsUFuHCiwVm88kvUvbvJbjj4be_IdNwpfdfXz-vq6NeEwlKEDLtD9oMVop_kEf5HEBkiipBrcn10h17XvYPuc6lA7Z4Y8IjvSjLVydXmcabmslwreMysD1ZINjzadjlJxiIKWCeS_3OJ4dxMTirt8HMUl8cRQafTjSOBJIZNtoNiT5rr5_5SYfEQW8v25RZcitkL0Lrg1mkSutRR00EE3zMelQBGR0sf8jDgBRiPQ1-sSgaIicIciZ2ysiPdkQZBIDpIFnvqed4yKY9gZCn-ASztoe1JhJvzWUwO7Nyz1Mb6pxAV0aQNfb0rDMTPNtyF4z7kgtFcsr5SXiJUa13bm0G2QvEdhl177poghh2RDaT5tcEmiRRvdQWBTeVgFyjrX3-29TZCT4z8VyvDxPPIUIi2rN8-9lN6mmsF0KhlyKe4jUuDwK7dc6Q0gZyjKiE3n-ygErrlbOYU16MGQiJQRV6Z8j38OSD4Lf5-SzsgkAa6Zbv95Zf8TZRS-fuagiXGZcmfdO9zXkuNlRlGguEUpx520SANRciPIBZxFBDXga6kcT9Hfha0n97Mhq57kFRe2Cox7qpq79x9TjUvHOZkWMSv2KmZpoF0wbI2NvlZngbW6Z1hC-X4C3evilX7O498r45Ct7PNjq11Qjso82DwMCAwEAAQ==

More to come

You can use Fastly’s token issuer endpoint, set up your origin, and try out beta Apple clients today. But the best is yet to come. 

Fastly is proud to invest, engage, and create technology and products that exemplify our belief that security and privacy are critical to a more trusted internet. We are actively working with our partners in the standards community to add more features to Private Access Tokens – like rate limiting for media protection and attestations for more client properties. There are exciting potential applications of this technology: consider what you could do with cryptographic guarantees that you’re exposing only and exactly what a website needs to know about a user – like their age. Providing an explicit guarantee on this sort of data flow can protect both users and websites.

And last but not least, keep your eyes peeled for simple-to-use, automatic configuration of Private Access Tokens to protect your website – with the ease of use and effectiveness expected from our next-gen WAF (powered by Signal Sciences) and the speed and scale of our developer-friendly Fastly edge cloud platform.

The DevOps Roadmap to Security

Looking for ways to unify with DevOps? This ebook will help security practitioners navigate fundamental DevOps principles and suggest realistic ways to leverage production visibility. Download the eBook