Clarification on Secure Handling of authenticationToken for Wallet Pass Updates

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:

  1. If a user adds the same pass twice on the same device, should the authenticationToken remain the same in both cases?
  2. 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.

Clarification on Secure Handling of authenticationToken for Wallet Pass Updates
 
 
Q