How Private Access Tokens (PATs) in iOS 16 Will Impact Bot Detection

A consistent challenge in cybersecurity for years has been validating users—that is, determining who is a real user and not a bot. This is generally done with one of several CAPTCHA systems that have negative impacts on both user experience and user privacy. Some traditional CAPTCHA providers know a lot about users (their IP address, device details, interactions with the page, etc.) and can tie it to other sites users have visited, building a profile of each users’ browsing history across sites and devices.

Private Access Tokens (PATs), a new technology for verifying human users, do not require any user input. Are these the answer to mitigating malicious bots without harming the user experience, all while protecting user privacy?

In this article, we will address the following:

> What are Private Access Tokens?

• • PAT Architecture
  • Data Exchange Flow

> What are the benefits of Private Access Tokens?

> What are the limitations of Private Access Tokens?

> Why PATs Are Not Enough (And What to Use in Addition)

> How DataDome Will Process Private Access Tokens

> Conclusion

What are Private Access Tokens?

iOS 16 and macOS Ventura users can opt in to a new Apple feature called Private Access Tokens (PATs). PATs are intended to help verify human users without displaying a CAPTCHA. 

Using a combination of device details with the user’s Apple ID, PATs tell websites whether or not a user is legitimate. PATs are a feature developed as a small part of the Internet Engineering Task Force (IETF)’s Privacy Pass Protocol. As the body that defines standard operating internet protocols, IETF created the Privacy Pass Protocol to ensure people can browse the web securely without constant data collection. With PATs, user data is hidden and anonymized throughout the token request and granting process, so tokens cannot be tied to a specific device.

Because PATs were created with privacy in mind, the tokens cannot be linked to specific users through site verification. As explained by Apple in a Worldwide Developer Conference (WWDC) 2022 session called “Replace CAPTCHAs with Private Access Tokens”—“Servers that receive tokens can only check that they are valid, but they cannot discover client identities or recognize clients over time.” 

PATs are meant to help validate users as human when a website might be uncertain. Instead of having to click on all tiles that show a certain item, or check a box saying they’re not a robot, Apple will use PATs to verify users’ legitimacy without any user input. This could improve the user experience across websites, and avoid the pain points associated with CAPTCHAs.

PAT Architecture

The PAT architecture requires four different parties to work together to verify the user whenever a request is made:

• Origin: The website, application, or API receiving the request from the client. The origin must look for and request a token from the client.
• Client: The tool being used to make the request to the origin, such as an internet browser or mobile app.
• Mediator: The party that identifies and authenticates the client using information such as its IP address, account name, or other device identifiers. The mediator then anonymizes the client and relays information to the issuer.
• Issuer: The party that generates and issues the PATs to the client on behalf of the origin. The issuer should also anonymize the origin to the mediator.

Data Exchange Flow

When a user makes a request that requires verification (and might lead to a CAPTCHA challenge), such as creating a new account on a website or mobile application:

1. The client submits the request to the origin.
2. The origin requests a token from the client, directing them to the issuer.
3. The client forwards the request to the mediator.
4. The mediator verifies and forwards the client’s anonymized details to the issuer, requesting a token.
5. The issuer checks the information against the origin’s policies.
6. The issuer generates and issues the PAT to the mediator, which passes it to the client.
7. The client submits the PAT to the origin.

What are the benefits of Private Access Tokens?

With traditional CAPTCHA systems, particularly Google’s reCAPTCHA v3, user privacy is not a focal point. The traditional CAPTCHA provider knows the website a user is visiting, the user’s IP address, device details, interactions with the webpage—and the provider can tie all of that data to other sites the user has visited. 

Therefore, if your business uses a traditional CAPTCHA, the provider can build a profile of your users’ browsing history across various sites and devices. That means some businesses could be unknowingly sacrificing the privacy of their users and/or customers in an attempt to verify the users are human.

PATs are one way for users to be validated without having to solve a CAPTCHA challenge. User details cannot be collected because PATs are anonymously authorized, and generally have a low impact on user experience. Additionally, developers have an easier time verifying if the user comes from a genuine (non-rooted) device with a signed (unmodified) application.

While hackers could potentially create fake identities or use multiple mediators tied to different true identities, PAT usage should force the cybersecurity ecosystem to evolve. Other practical mitigations could include:

• Allowing an issuer to learn the properties of a mediator—specifically, which stable client identifier is authenticated by it—to determine whether the mediator is acceptable for an origin.
• Allowing an origin to choose an issuer based on the types of mediators accepted by the issuer, or allowing the origin to communicate its constraints to the designated issuer.
• Allowing an origin to direct a user to a specific issuer based on visible client properties, such as those in the HTTP User-Agent string.

What are the limitations of Private Access Tokens?

Mediator Reputation

As explained in sections 1.3 and 1.4 of IETF’s description of PATs, the mediator is one of the most important parties involved in the verification process, as it alone can detect fake client identities in the PAT architecture. The issuer must rely on the mediator’s reputation, and tokens should only be issued to known and reputable mediators. 

Because a user might be able to “create an arbitrary number of client identities that are accepted by one or more mediators, a malicious user can easily abuse the system to defeat the issuer’s ability to enforce per-client policies.” Therefore, the mediator needs to be able to distinguish true human users from bots on its own.

The mediator is responsible for “weeding out fake client identities in the PAT architecture”. Besides a few security countermeasures such as IP rate limiting that are discussed in the IETF draft, there are no more details regarding how mediators are going to manage to weed out fake client IDs (which is not an easy task).

Request Configuration

The PAT protocol also requires the website owner to define when to request a token. Because of this, PATs are similar to reCAPTCHA v3 in that they require a heavy amount of work from the webmaster. How do you determine when to request a token versus just allowing a user in?

User Experience (UX)

As stated in the IETF draft, obtaining and validating a token can add user-perceivable latency, since it involves interactions with third-party servers. While this may not be a concern in situations where the token verification can be performed in the background, this can negatively impact UX in other situations. 

For example, if web scrapers were gathering information from your product pages, you would need to find a way to stop them. Distributed scrapers tend to make one request per IP address on different project pages. If you want to stop or catch the scrapers, you would need to block them on each product page request they make from each IP address. Doing this with PATs would add latency on each product page load—which impacts genuine users as well.

Thus, to protect websites against distributed scrapers that make a single request per IP, it will still be important to use other signals beyond PATs to enable a good UX (e.g. fast page loads).

Device/Operating System (OS)-Specific

Currently, only Apple users on iOS 16 and/or macOS Ventura who consent to using PATs have access to the PAT security feature. Android, Windows, and legacy Apple devices will not be able to request or send PATs to validate their legitimacy. When PATs begin to be used in production, most users will still be on devices that don’t yet support the new technology. Since most users still need legacy methods of validation (such as CAPTCHA), bots will try to exploit the loophole by pretending to be users of devices that don’t officially support PATs.

Not Linked to Devices

PATs are not linked or linkable to a specific device, which is good when it comes to privacy. However, it decreases the security benefits—and will certainly be exploited by bots. Perhaps on certain noncritical pages or endpoints where businesses might prioritize UX above security, PATs could be a viable option. But it is critical to have strong detection on critical endpoints such as login, account creation, and payment.

PATs Alone Are Not Enough—Here’s Why:

PATs are an alternative to challenging a user with a CAPTCHA for validation. They are intended to verify the authenticity of a device, but they are quite limited, particularly by OS. Bots can and will pretend to be users of legacy devices that don’t support PATs to legitimize the refusal to send tokens. 

At DataDome, we see many cases of bots running on legitimate devices in an attempt to infiltrate real mobile apps. Bot devices have the same level of access to PATs as legitimate users. 

It’s important to assess both the authenticity of a device/application and the humanity of the user. Because of this, Apple even recommends using real-time bot protection in addition to PATs. An efficient bot protection solution will analyze several signals, including PATs, to determine whether or not a user is human.

How DataDome Will Process Private Access Tokens

PATs, while promising, are still a fledgling technology. DataDome intends to continue watching PAT development through the upcoming months and years. 

As PATs evolve, we may decide to adapt how we utilize the signal to hold more weight in verifying users as humans vs. bots. There could be a future in which DataDome would act as the origin for our customers—meaning we would request the PAT from the user via the mediator and issuer. (Example schema below.)

Conclusion

While a definitive win for user privacy and (in many cases) user experience, PATs alone will not solve the main cybersecurity problems we face today.

Legacy Apple devices and operating systems, as well as non-Apple users, will not be able to use PATs to validate their authenticity. Most users will still be served CAPTCHA challenges, and traditional CAPTCHAs will continue to gather user data. Another possible issue is the need for PAT mediators to be reputable and able to distinguish between human and bot users by themselves. 

PATs are not a bot detection software, and cannot mitigate malicious bot traffic on their own. PATs are a useful signal to include when deciding whether a user is a human or not, but they should be used alongside a good bot detection (and protection) solution. 

A new technology, PATs will continue to evolve over time. DataDome will consider PATs as a signal source alongside the many other client- and server-side signals already used  in determining whether a request comes from a bot or a human.