We are designing account deletion and token storage for Sign in with Apple across a native iOS flow and a web-based flow used by our Android client. Apple’s documentation describes a successful /auth/revoke request as revoking the user session associated with the supplied token. It also states that the client_id used for revocation must match the client_id used during authorization. We need to understand the documented revocation boundary: whether it is limited to the supplied token or session, or whether it also affects other tokens associated with the same Apple user, client ID, primary app group, or Developer Team. Definitions: A: Our primary App ID. B: A Services ID associated with primary App ID A. C: Another App ID grouped with primary App ID A. D: An App ID in the same Developer Team but belonging to a different primary app group. Assume that the tokens in the questions below belong to the same Apple user. Questions: For a refresh token issued under each of A, B, C, and D, which authorizations or tokens under A, B, C, and D are invalidated by a successful revocation request? Please clarify the result separately for each starting client ID (A, B, C, and D), rather than assuming that the relationship is symmetrical. Please also state whether the result differs depending on whether the identifiers belong to the same primary app group. If multiple refresh tokens have been issued for the same user under the same client_id, does revoking one refresh token invalidate the other refresh tokens, or only the user session associated with the supplied token? If an access token is revoked, is the refresh token from which it was derived also invalidated? Conversely, if a refresh token is revoked, are access tokens derived from it also invalidated? When processing an account deletion request, is revoking one stored token sufficient to remove the user’s complete Sign in with Apple authorization for our Developer Team, or must every refresh token and access token that we have stored be revoked individually? We are asking for the documented behavior that an implementation can safely rely on, rather than behavior observed in a single test. If the only guaranteed scope is the user session associated with the supplied token, please confirm that explicitly.