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.

I have set up Sign in with Apple. I can see the Sign in with Apple popup with the Continue button on the sign-in button click. Clicked on the Continue button. Then selected email and clicked on Continue with Password button. After entering the password activity indicator spins and the continue button disappears after a few seconds button enables but the activity indicator spins continues, not getting callbacks, and not able to understand what happens. Please help to resolve this issue.

With most OAuth systems a call to https://service/oauth/revoke?token={token} or along those lines should disconnect the user, I can't find anything like this in Sign in With Apple. Is this an option? It is needed for when a user removes their account 🙂

I am working on to revoke the apple access token on deletion of user account. I hit the api, attaching a photo of the postman response Even though I got the success response - 200, but the access token is still not revoke, Able to see the apps linked with Apple ID. Please help me out to fix that issue

Hi! I have a problem. I recently signed up for an online clothing app account using Sign in with Apple ID. However, I am not able to receive any emails from them. I have forgotten my password, and need to reset it. How can I see emails from them? They are not forwarded to my verified email address (I have checked all folders including Junk). Thank you very much for your help.

Per Account deletion requirement iOS If your app offers Sign in with Apple, you’ll need to use the Sign in with Apple REST API to revoke user tokens when deleting an account. Referring to this answer, we are trying to send this revoke token API on our server-side. Here are some snippet privateKey = fs.readFileSync("xxxxxxxx.p8") client_secret = jwt.sign({ iss: 'xxxx-***-xx-xxxx-xxxxxxxx', iat: Math.floor(Date.now() / 1000), exp: Math.floor(Date.now() / 1000) + 1200, aud: 'https://appleid.apple.com', sub: "sample.com" }, privateKey, { algorithm: 'ES256', header: { alg: 'ES256', kid: 'xxxxxxxxxxx' } }); data = { 'token': token, 'client_id': "sample.com", 'client_secret': client_secret }; body = qs.stringify(data) opts = protocol: 'https:' host: 'appleid.apple.com' path: '/auth/revoke' method: 'POST' timeout: 6000 headers: 'Content-Type': 'application/x-www-form-urlencoded' 'Content-Length': Buffer.byteLength(body) // call https to send this opts message And the status code of the above codes could be 200. However, the response code 200 of revoke token api The request was successful; the provided token has been revoked successfully or was previously invalid. It seems the status code 200 includes the provided token was previously invalid. How could we distinguish whether the revoke token API was returned by the invalid token or revoked successfully? We also try to test this revoke token API through curl with invalid client_secret and token, the status code 200 could be returned either. It is so weird. curl -v POST "https://appleid.apple.com/auth/revoke" \ -H 'content-type: application/x-www-form-urlencoded' \ -d 'client_id=***.xxxx.yyyy' \ -d 'client_secret=ddddddeyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IlBGUVRYTTVWUlcifQ.dddd.DmMifw6qWHMqKgDIbO8KrIzDvbF7T4WxxEo9TmtN0kmTISsi8D8FG52k_LPGkbNEnS_-w_SRimEKIH1rsuawFA' \ -d 'token=dddddd' \ -d 'token_type_hint=access_token' > POST /auth/revoke HTTP/1.1 > Host: appleid.apple.com > User-Agent: curl/7.77.0 > Accept: */* > content-type: application/x-www-form-urlencoded > Content-Length: 240 > * Mark bundle as not supporting multiuse < HTTP/1.1 200 < Server: Apple < Date: Thu, 09 Jun 2022 07:36:31 GMT < Content-Length: 0 < Connection: keep-alive < Host: appleid.apple.com

In my mobile app, when users choose to "sign in with apple" and choose to hide their email, I am unable to send emails through the private relay email that apple provides me with. The Sign-in-with-apple feature works perfectly fine in the app, I get a successful response, get the needed user information, and can register them and sign them into the app. If a user chooses to share their email, then I am able to successfully send the user emails so the problem is seemingly only with the private relay service. In my apple developer console I have configured apple-sign-in and have verified my email sources including my domain name and the email that is attempting to send emails. I am using SendGrid to send my emails and I have followed the documentation to verify the email address needed for apple-sign-in as well. All three sources display a green checkmark indicating they have been SPF verified. Despite this, I am still unable to send emails through Apple's private relay service. The relay email address never forwards the mail to the user's actual address and so the user never sees the email. I'm not sure if there is anything else I need to do after verifying my email sources but it seems like I have followed all the steps to properly configure everything. Would anyone happen to know why I still cannot get the relay service to work properly? Any help is greatly appreciated. Thank you!

I am investigating Sign in with Apple in detail and its relation with OpenID Connect. In line with this, it is known if Sign In with Apple supports the OpenID spec Logout endpoint? (https://medium.com/@robert.broeckelmann/openid-connect-logout-eccc73df758f) (https://openid.net/specs/openid-connect-frontchannel-1_0.html) Thanks, Dan

Usually, people respond to these types of posts with things like: "honor the users choice here" This isn't about choice. We are a bank. A literal bank. For regulatory reasons, we need to collect the user's email during onboarding. It's used for legal communications including bank statements, as well as compliance with anti money laundering laws. In fact, email is one of the least invasive things we collect. Banks need to collect SSN, mailing/billing addresses, full legal names, phone numbers, and more. If Apple's response was, "there's no way to disable Hide My Email", then we would be legally required to have entirely separate UI after the "Sign in with Apple" screen where we collect and verify their real email. Two email auth screens. By telling us to NOT disable Hide My Email, you're saying that we need to have separate email collection UI, or we need to abandon Sign in with Apple entirely and go with custom email/password auth.

Hi all, I have the "Sign in with Apple" capability within my web application. To make it work, I've got the redirect URI defined in the Apple developer console. Now, for development environments, I'm required to define new redirect URIs every time. For example, I have "feature123.company.com", and the Apple sign in won't work until I define this URI in the Apple dev console. I want to solve this by having a constant URI configured, say "apple.company.com", and then have a proxy on that address, that will redirect any incoming traffic to the appropriate URL (based on the "state" param). I implemented the same with Google and Facebook logins, but for some reason I can't get the Apple login to work. After I login to Apple in the pop-up, and click the "Continue" blue button, I see an "authorize" request with 200 response, but the pop-up doesn't close as expected. The view remains and the "Continue" button is still available, clicking it again sends another "authorize" request but this time it fails with error 403. Any ideas?

As of April 2020, I believe Sign In With Apple must be an option for social apps. This requires the user sets up Two Factor Authentication (e.g. Face Id) on their device.If the Apple Id account is an under 13 child account created through Family Sharing, the user cannot completely set up 2FA, although it can be switched on, but never switched off. For example:I create a child account via Family Sharing on my device, then log out and log back into my device using that child account.I go to an app that uses Sign In With Apple and attempt to sign in. It shows the following message "Two-Factor Authentication Required".I then follow the dialogs to set up 2FA, at some point in the flow I hit this error message: "This Feature Cannot be Set Up". I cannot add 2FA to my child account.However I can go into Settings and switch it on, but I can't set up face or touch id. But ok, I'll just try and sign into that app againWhen I try Sign In With Apple after (partially) enabling 2FA, I see this error: "Cannot Create Account. Your Apple ID cannot be used to create accounts for other apps"So there it ends, as a &lt;13 child account I can neither set up or use 2FA for signing into apps. Is this inability to set up 2FA due to COPPA? Could this be circumvented simply by using their email / password to sign in?If could this please be surfaced more clearly in the documentation. It took a good few days of testing to discover the edges of this feature and is confusing for both developers and parents alike.

Ive created primary app id and service id in Apple Developer Portal - Identifier and enabled "Sign in with Apple". However after construct the redirect url: https://appleid.apple.com/auth/authorize?response_type=code&amp;response_mode=form_post&amp;client_id=com.bolt.account.test.client&amp;redirect_uri=https://account.bolt.com&amp;state=merchant_token=%26provider=apple&amp;scope=name%20email and login to apple, an 400 error returned from /consent endpoint with the following error message: code: "-310003" message: "Sign in with Apple isn't allowed for the app." suppressDismissal: false What should I look to verify if the sign in with Apple is enabled or not? Thanks in advance for any suggestions!

I implemented Sign in with Apple in our backend using Django. This backend serves data to the web app and to the mobile app. After a lot of work, I got these both to work by using a Service ID for the web app and an App ID for the mobile app. The issue is that a user that creates their account via the mobile app can't login using the web app, the system returns an error informing that that email address is already used by another user. The Service ID's primary App ID is the one used for the mobile app. Should I not use two different IDs (Service ID and App ID) to handle login via web app and mobile app? Is there a way to merge those? What am I missing? Help would be much appreciated!!

I have published an app on the App Store using my personal account which I would now like to transfer to a new separate developer account (which I also own). The app does not use iCloud, push notifications, or any in-app purchases. It does, however, use Sign In with Apple for user authentication. I have read the two Apple documents that pertain to transferring an app, but they go a little over my head, especially the user migration process. What is the user experience if I do not migrate users and simply transfer the app without handling this? Assuming the app handles expired authentication correctly, will they simply be asked to sign in to the app again and all will be well? Or will the user ID be different, meaning that "signing back in" will actually create a new account? In other words, is the user migration process only intended to minimize user inconvenience by maintaining logged-in sessions, or is it essential for user accounts to remain tied to their data? Thanks in advance for any advice.

Has anyone else experienced users being unable to reply to communications with them? If so, was there a solution? tldr; Email from our domain to users ####@privaterelay.appleid.com email works correctly. User replies to myemail_at_mydomain_com_####_8800cbcb@privaterelay.appleid.com fail. I have emails properly being sent and received to my Sign in with Apple users via the methods described here: https://help.apple.com/developer-account/?lang=en#/devf822fb8fc The issue is if a user replies to the email. They get an immediate notice that the email was undeliverable. According to the chart available within the docs, it seems like I should not have to configure the ability to receive replies. This should be handled by the relay server. https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/communicating_using_the_private_email_relay_service Here's the failure email for reference (with private emails redacted of course) This is a system-generated message to inform you that your email could not be delivered to one or more recipients. Details of the email and the error are as follows: <myemail_at_mydomain_com_####_8800cbcb@privaterelay.appleid.com>:    host smtp3.privaterelay.appleid.com[17.56.9.16] said: 550 5.1.1 Relay not    allowed (in reply to RCPT TO command) Reporting-MTA: dns; mr85p00im-zteg06011601.me.com X-Postfix-Queue-ID: 1418E920ABA X-Postfix-Sender: rfc822; user@email.com Arrival-Date: Thu, 1 Oct 2020 21:09:09 +0000 (UTC) Final-Recipient: rfc822; myemail_at_mydomain_com_####_8800cbcb@privaterelay.appleid.com Original-Recipient: rfc822;myemail_at_mydomain_com_####_8800cbcb@privaterelay.appleid.com Action: failed Status: 5.1.1 Remote-MTA: dns; smtp3.privaterelay.appleid.com Diagnostic-Code: smtp; 550 5.1.1 Relay not allowed From: User Name <user@email.com> Subject: Re: Test Sending Date: October 1, 2020 at 2:09:08 PM PDT To: Customer Service <myemail_at_mydomain_com_####_8800cbcb@privaterelay.appleid.com> Test Reply On Oct 1, 2020, at 2:02 PM, Customer Service <myemail_at_mydomain_com_####_8800cbcb@privaterelay.appleid.com> wrote: Welcome

Hello, We are planning to migrate our App from current developer account to another account. As our app is using Sign in with Apple, we have to migrate user scoped identifiers from current employer to recipient account. As I was reading articles on developer site (https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team) My understanding regarding migration process is as follow: Generate Access Token (we didn't stored user access token) using sender details (client_secret) Generate Transfer_sub using above access token and save it Transfer App and accept it on recipient side. Generate Access token for recipient (using recipient client_secret) Generate team scope identifier for new team using previously generated transfer_sub and above access token and update older identifier with newly created identifier in our own database. Use new identifier for future requests.  Regarding above, please answer following queries: Please confirm me if my understanding regarding migration process is correct as I documented above? Secondly for all the users who have signed up before this migration, if I generate new scoped identifiers for them, it will work for them without requiring them to sign in with Apple again? Otherwise asking users to sign in again would be painful and we might lost users. All of the users who signed up after migration, for them normal sign in flow will work (getting access token from apple sign in and getting identifier from apple as it was working before migration)? These identifiers will automatically be associated to new developer account? I have tried following apis (generate access token, generating transfer_sub) and they are working fine, but when I run api to generate new-scope identifier for recipient using transfer_sub, it failed with error (invalid_request). So my understanding is that, I can only generate new identifier for new developer account only  the app will be transferred?Please confirm me this. Kindly respond to all of above queries as there isn't good documentation available on internet. So we want to be fully confident in this process from our side before app migration. Thanks