Hi,
We are operating a service that uses Sign in with Apple for user registration and login. As part of our security incident response and periodic security improvements, we are planning to rotate the private key used to generate the client secret (JWT) for Sign in with Apple.
I have read the Human Interface Guidelines and the AuthenticationServices documentation, but I could not find a clear description of the behavior and user impact when rotating this private key. I would like to ask the following questions:
Background:
- We issue a Sign in with Apple private key (with a Key ID) in our Apple Developer account.
- Our server uses this private key to generate the client secret (JWT).
- This is used for Sign in with Apple login on our web / mobile app.
- We are planning to invalidate the existing private key and switch to a newly issued one.
Questions:
-
Impact on existing logged-in sessions
- Will rotating the private key force already logged-in users (who previously signed in with Apple) to be logged out from our service?
- Can the user identifier (such as the "sub" claim) for existing Sign in with Apple users change due to key rotation?
-
Recommended frequency and best practices
- Does Apple recommend rotating this private key only when it is compromised, or on a regular basis?
- If there are any official documents or examples that describe how to safely perform key rotation in production, we would appreciate a pointer.
-
Impact on marketing / analytics
- We are using user IDs (linked via Sign in with Apple) for analytics and marketing attribution. Is there any expected impact on such use cases caused by rotating the private key?
- For example, is there any possibility that user identifiers change as a result of key rotation, or anything we should be careful about from a data linkage perspective?
Our goal is to rotate the private key in a secure way without causing service downtime, mass logouts, or loss of account linkage.
If there is already an official document that covers this, please let me know the URL.
Thank you in advance.
Hi @TakuyaOkamoto,
You wrote:
Will rotating the private key force already logged-in users (who previously signed in with Apple) to be logged out from our service?
No, rotating the private key doesn't log out existing users.
The private key ID is used to validate your client secret (JWT) in your authorization and token validation requests. So on those Apple endpoints (/auth/authorize, /auth/token, /auth/revoke, etc.), the user may indirectly fail to refresh their user session due to a failed token validation due to an invalid private key. However, immediately using the rolled private key and refreshing the user tokens mitigates this issue.
Next, you wrote:
- Can the user identifier (such as the "sub" claim) for existing Sign in with Apple users change due to key rotation?
No. The user identifier and the private email relay has a one-to-one association with the user and the developer team. A change to the private key does not affect this layer of Sign in with Apple.
Then, you wrote:
- Does Apple recommend rotating this private key only when it is compromised, or on a regular basis?
You can create 2 private keys, and both can be active simultaneously. First, generate the new key in the Developer portal, test your backend and validation implementations, deploy to production, and only after confirming a healthy transition, purge the old key from your systems and revoke from the Developer portal.
Lastly, you wrote:
- We are using user IDs (linked via Sign in with Apple) for analytics and marketing attribution. Is there any expected impact on such use cases caused by rotating the private key?
No, the user ID and private email addresses are unaffected by private key rotations.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
