The revoke tokens endpoint (/auth/revoke) is the only way to programmatically invalidate user tokens associated to your developer account without user interaction. This endpoint requires either a valid refresh token or access token for invalidation, as Sign in with Apple expects all apps to securely transmit and store these tokens for validation and user identity verification while managing user sessions. If you don’t have the user’s refresh token, access token, or authorization code, you must still fulfill the user’s account deletion request and meet the account deletion requirement. You'll need to follow this workaround to manually revoke the user credentials: Delete the user’s account data from your systems. Direct the user to manually revoke access for your client. Respond to the credential revoked notification to revert the client to an unauthenticated state Important: If the manual token revocation isn’t completed, the next time the user authenticates with your client using Sign in with Apple, they won’t be presented with the initial authorization flow to enter their full name, email address, or both. This is because the user credential state managed by Sign in with Apple remains unchanged and returns the.authorizedcredential state, which may also result in the system auth UI displaying the “Continue with Apple” button. Respond to the credential revoked notification Once the user’s credentials are revoked by Apple, your client will receive a notification signaling the revocation event:  For apps using the Authentication Services framework to implement Sign in with Apple, register to observe the notification named credentialRevokedNotification. For web services, if an endpoint is registered for server-to-server notifications, Apple broadcasts a notification to the specified endpoint with the consent-revokedevent type. When receiving either notification, ensure you’ve already performed the following operations to meet the requirements of account deletion: Deleted all user-related account data, including: The token used for token revocation; Any user-related data stored in your app servers; and Any user-related data store in the Keychain or securely on disk in the native app or locally on web client. Reverted the client to an unauthenticated state. Securely store user tokens for account creations For all new user account creations, follow the expected authorization flow below: Securely transmit the identity token and authorization code to your app server. Verify the identity token and validate the authorization code using the /auth/token endpoint.  Once the authorization code is validated, securely store the token response — including the identity token, refresh token, and access token. Validate the refresh token up to once per day with Apple servers (to manage the lifetime of your user session and for future token revocation requests), and obtain access tokens (for future token revocation, app transfer, or user migration requests). For information about verifying an identity token and validating tokens, visit Verifying a user and Generate and validate tokens. If you have questions about implementing these flows, including client authorization, token validation, or token revocation, please submit a Technical Support Incident.

My existing chrome extension has "Sign in with Apple" given that we have iOS users. When user clicks "Continue with Apple" button in the extension log in pop up, this is what we do: javascript window.open( 'https://appleid.apple.com/auth/authorize?client_id=' + clientID + '&redirect_uri=' + backEndURL + '&response_type=id_token%20code&response_mode=form_post&scope=email%20name', 'Sign in with Apple', 'height=500,width=400,left=600,top=200,status=no,location=no,toolbar=no,menubar=no' ) In chrome, this opens a popup window with that URL. In Safari Converted Web Extension, it opens custom Apple sign in flow, where it says: "Do you want to sign in to XXX with your Apple ID YYY?" and then with my mac password I'm able to authenticate. Afterwards, nothing happens. Expected: a redirect to the URL specified in the window.open. Now let's do a trick: I'll wrap the above window.open code into javascript setTimeout (() = {window.open (...)}, 3000) Because of security reasons, safari then won't open the popup after 3s and will display a notification in the toolbar "Popup blocked..". If we allow the popup, then it finally opens as a normal window popup and after sign in, it redirects to our backend and it successfully authenticates. Any ides what how to solve this? P.S. We're not able to use embedded Sign in with Apple JS - https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/configuring_your_webpage_for_sign_in_with_apple script because we can't host a remote code in the extension (it will be deprecated soon). So, we arere using this. - https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/incorporating_sign_in_with_apple_into_other_platforms