feat(api): revoke Sign in with Apple tokens during account deletion - #65
Open
MehrshadFb wants to merge 1 commit into
Open
MehrshadFb wants to merge 1 commit into
MehrshadFb wants to merge 1 commit into
Conversation
API unit-test coverage
Unit suite only; controllers are exercised by the e2e suite. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Apple requires apps that offer Sign in with Apple to revoke the user's Apple tokens when their account is deleted, and our saga did not. Auth0 obtains those tokens when it exchanges the authorization code and keeps them on the user's Apple identity, but deleting the Auth0 user just throws them away without revoking anything. The visible effect is that the app stays listed as authorised under the person's Apple ID after they delete their account, their next sign-in skips Apple's consent screen, and Apple never sends their email to Auth0 again. It is also what App Store review checks. This PR adds the missing step on top of #56: for an
apple|identity the saga reads the refresh token from Auth0, revokes it against Apple's/auth/revokeendpoint with a freshly signed client secret, and only then deletes the Auth0 user. The order matters because the token lives on the Auth0 user. Apple answers 200 for a token that is already revoked, so a resumed saga repeats the step safely, and nothing new is stored in our database.Two kinds of failure, handled differently on purpose. If Apple cannot be reached, the saga stops before the Auth0 delete and the reconciler retries later with the token still in place, the same shape as an Auth0 outage. If Apple refuses the request, or there is no token to revoke because the credentials are missing or the management client cannot read identity tokens, the deletion goes ahead and an audit error is logged, because Apple's own guidance is that the deletion must still be honoured and retrying would only delay it. Accounts from every other connection are untouched. Nothing about the endpoint or the OpenAPI spec changes, so mobile needs no regeneration. To switch it on: set
APPLE_SIWA_TEAM_ID,APPLE_SIWA_KEY_ID,APPLE_SIWA_PRIVATE_KEYandAPPLE_SIWA_CLIENT_ID(the iOS bundle identifier, the same values the Auth0 Apple connection uses), grant the management applicationread:usersandread:user_idp_tokens, and enable refresh-token storage on the Apple connection. The full checklist is inapi/docs/authentication.md.Part of #31