Private Access Tokens let a device vendor vouch that a client is a real device without telling the website who the person is.
The website learns that an issuer stands behind the client, and it does not receive the person's name, account, or a lasting identifier.
How it works
A mobile banking app can ask for a token when a signup looks automated, and the phone maker attests that the request comes from a genuine device.
The bank still does not learn which person the maker associates with that phone.
The control raises confidence that a script is not pretending to be a normal handset, while avoiding a login wall that would identify every honest visitor.
It depends on the issuer's checks, so a website should treat the token as one signal among others.
Concrete examples
- A media site requests a token before it serves a full article to a client that otherwise looks like a bulk downloader.
- A ticket shop uses a token at the start of a sale so a real phone can proceed without sending the customer's identity to a new vendor.
- A bank compares a failed token with other signals before it blocks a login that might still belong to a traveling customer.
Protective measures
- Accept tokens only from issuers you have chosen, and reject a token that does not match the site that asked for it.
- Do not store the token in a way that lets you rebuild a history of the same person across unrelated visits.
- Keep a fallback for customers whose devices cannot obtain a token, so they are not locked out of the bank with no other path.
- Review issuer guidance when phone software changes, because an old expectation can start failing for honest devices.
Related articles
Readers who want more on a mobile banking app should open What are parental controls? next.
For day to day work on a mobile banking app, add What is a hacker? to the same reading list.
People who look after a mobile banking app compare this explanation with What is an Internet Protocol address?.