Sign in with Apple and Account Deletion: revoke tokens and remove app data

Separate app-account deletion from Apple authorization

Treat deletion as a coordinated lifecycle rather than a single API call. The user is asking your service to end the account relationship: remove or de-identify the data your product controls, stop future access, and deal with the credential that let the user sign in. Apple token revocation handles the last part. It does not know about your database rows, uploaded files, analytics events, customer-support exports, or copies held by other processors.

Start by writing down the system boundaries involved in one account. Include your authentication provider, application database, object storage, search index, notification service, billing system, and any analytics or support tools that receive account identifiers. For each one, decide whether the deletion flow removes data, disconnects it from the account, retains a restricted record for a stated reason, or queues an operation for later completion. Confirm these choices against your product obligations and retention policy rather than promising that every trace disappears instantly.

Sign in with Apple can return a stable user identifier and, depending on requested scopes and the user's choice, an email address and name. The email may be a private relay address; name information may be supplied only during the first authorization. Check what your backend actually persists. A first login may have copied profile details into several systems, while later logins may not provide the same name object again. Do not treat revoking the token as a way to recover or erase those copies.

Build an in-app deletion path that finishes the job

Put the control somewhere a signed-in user can find, such as account settings. Label the action clearly as account deletion and explain the important consequences before confirmation: loss of access, what information is removed, any data retained for a limited purpose, and how long asynchronous processing may take. Avoid turning a support email, a temporary account pause, or a sign-out button into the only apparent deletion choice.

Require a reasonable confirmation step to prevent accidental requests, but do not create unnecessary obstacles. If recent authentication is needed before a destructive action, explain why and give the user a direct way to reauthenticate. Once the request is confirmed, record a durable deletion job and make its status recoverable if a network request or worker fails. A transient provider outage should not make the request vanish.

Design the server workflow to be idempotent. Repeated taps, webhook retries, or a background job restarting should not recreate a deleted account or leave the user in a partially active state. First prevent new sessions and invalidate your own app sessions. Then use the available Sign in with Apple credential to revoke the provider authorization, and continue through the data stores and processors in your inventory. Remove local app data where your app can do so, clear user-specific caches and keychain entries, and sign the client out when the workflow completes.

Keep the user informed with a clear completion state. If some work is asynchronous, distinguish “request received” from “deletion completed,” and provide a support route for an exception. Make sure the in-app flow still works if the user cannot sign in normally, for example by providing an account recovery step that does not silently abandon the deletion request.

Revoke the Sign in with Apple token safely

Apple provides the /auth/revoke endpoint to invalidate a user's Sign in with Apple tokens and associated authorization. A valid refresh token or access token is needed for the revocation request. If your server exchanges the short-lived authorization code as part of sign-in, establish a secure server-side process that can retain and use the required credential for deletion. Keep credentials protected on your backend; do not embed an Apple client secret or server credential in the iOS binary.

Treat the revoke call as one step in a larger workflow. A successful provider response means the token was invalidated; it does not certify that your own services deleted account data. Store a minimal, access-controlled deletion-job status if needed to retry a failed step, but do not retain the very user content or credentials the deletion job is meant to remove. Once the process no longer needs the token, erase it with the other account-related records.

If you no longer have a refresh token, access token, or authorization code, fulfill the app-account deletion request anyway. Apple documents a manual-revocation fallback: delete account data in your systems, direct the person to revoke access for your client, and handle the credential-revoked event by returning the client to an unauthenticated state. Build that fallback into your support and failure path instead of returning an error that blocks data deletion.

If you receive a credential-revoked notification, process it as a lifecycle event. Find the account using a verified provider identifier, remove associated data under your deletion rules, erase stored revocation tokens, and clear local state or sessions. For apps using Authentication Services, observe the credential-revocation signal and update the client. For a server integration, validate and process configured server-to-server events. Make these handlers safe to retry and prevent a late notification from accidentally creating a new account.

Verify the full deletion path

Test with accounts that represent the variations your production app supports: a real email, a private relay email, a user who did not supply optional profile data, and an account with stored content. Exercise both a successful token-revoke response and the missing-token fallback. Include a timeout or provider error, then confirm the deletion job resumes without restoring access or skipping downstream data stores.

Check observable outcomes, not only the confirmation screen. The deleted user should not be able to sign in and reach the old account; application records and owned media should follow the declared deletion policy; and the client should no longer present a valid signed-in state. Review logs, exports, and processor dashboards for residual identifiers, and document any retention exception and its end date. Keep deletion evidence minimal and protected.

Common mistake

The most common implementation gap is revoking Apple's token but leaving the app's own account active. Another is deleting the database row first and thereby losing the only credential or identifier needed to revoke the provider authorization and clean up related systems. Plan the order of operations and keep only the narrowly scoped state needed to finish a retryable deletion.

A third mistake is assuming Sign in with Apple always returns the same profile fields on every authentication. Persist the identifiers and profile fields your service legitimately needs when they are first provided, protect them appropriately, and make the deletion workflow independent of a later login prompt. Do not ask a user to provide a personal email merely because they chose Apple's private relay option.

Where Declora fits

Declora can put the Sign in with Apple Service Profile and account-deletion guidance beside your confirmed App Facts, so you can review the provider identifier and any email or name your app stores while preparing your App Passport and Public Pages. You still need to verify the production flow and perform deletion in your systems. Declora is informational, is not a law firm, and cannot guarantee store approval.

FAQ

Does revoking a Sign in with Apple token delete my app account?

No. Token revocation invalidates the provider authorization, but your app must separately delete or otherwise handle its own account records, content, sessions, and processor copies under its deletion process.

Must I still delete the app account if I no longer have Apple's token?

Yes. Apple says you must still fulfill the deletion request. Delete the account data you control and provide the documented manual authorization-revocation path, then handle the revocation event and sign the client out.

Should I keep a Sign in with Apple token indefinitely for future deletion?

No. Design a secure, limited-purpose process that can revoke authorization when needed, protect any token you must retain, and delete it when the workflow no longer requires it. Confirm the design against Apple's current developer documentation and your security requirements.