Hello there,
We’re currently integrating Apple Wallet pass functionality into our application and am looking for clarification around the automatic update flow. Particularly regarding secure management of the authenticationToken.
We’ve reviewed the documentation here:
From our understanding: When a user downloads a pass from our service, the .pkpass includes both a webServiceURL and an authenticationToken. Once the pass is added to Wallet, the Wallet app makes authenticated requests to our webServiceURL, using the token in the Authorization header. We then validate this token server-side to serve updates or handle device registration. So far, this flow is clear.
However, we’re looking for clarification on two key scenarios:
- If a user adds the same pass twice on the same device, should the authenticationToken remain the same in both cases?
- If the same user adds the same pass on a different device, should the authenticationToken also remain consistent across devices?
If the answer to both is “yes,” we assume that our backend must store the original authenticationToken in a retrievable form (not just as a hash) to regenerate the same pass for re-download or multi-device sync.
Our main question is:
What is Apple’s recommended or acceptable approach to storing authenticationToken values securely on the backend?
Should these tokens be:
- Stored in plaintext (e.g. in a protected DB field)?
- Encrypted using a symmetric key?
- Hashed (not reversible, but limits reuse)?
We want to ensure we align with Apple’s best practices for Wallet security and token management, especially in contexts where the same pass may be installed on multiple devices or reissued later.
Hi @gabe_pires,
You wrote:
[...] If a user adds the same pass twice on the same device, should the authenticationToken remain the same in both cases? [...]
Wallet prevents true duplication. A pass is uniquely identified by the combination of passTypeIdentifier and serialNumber. If a user attempts to add the same .pkpass again, Wallet will update the existing pass rather than create a second entry. The token identity is irrelevant as this scenario would consist of the same instance of the pass object.
Then, you wrote:
[... ] If the same user adds the same pass on a different device, should the authenticationToken also remain consistent across devices?
The authenticationToken is scoped to the pass—as I said above, the passTypeIdentifier and serialNumber pair), not to a particular device. Multiple devices installing the same pass will all present the same token to your web service, but with different deviceLibraryIdentifier and pushToken values.
You registration endpoint will look like the following example:
POST
/v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}/{serialNumber}
Authorization: ApplePass <authenticationToken>
Body: { "pushToken": "<device-specific-push-token>" }
So yes, the token is consistent across devices for the same pass, and your backend must account for N device registrations per token/serial number.
Next, you wrote:
[...] What is Apple’s recommended or acceptable approach to storing authenticationToken values securely on the backend?
This greatly depends on what operations your backend needs to support—we cannot prescribe a storage method for you. However, the recommended approach is to design your resistance flow around token rotation rather than token retrieval—thus, you can keep tokens in a non-reversible hashed form.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
