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.

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!

Do we have to offer user ways to delete game center? If it does, then how to do it? Is there any documents for reference? Thanks

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?

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 our video app, some users need to use an account provided by a third party (our sister company which provide mobile services like Verizon) because the package is subscribed via the third party company. We therefore provide more than one login method. In such case, do we need to include Apple sign-in as well? Thanks!

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 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

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!!

In the App Store guidelines it is stated as mandatory to provide sign in with apple. Is the app allowed to block users who register with "hide my email" and not allowing them to create an account? https://developer.apple.com/app-store/review/guidelines/#sign-in-with-apple

Hi, I'm trying to sign my Swift application (Extension to Apple Mail) but I didn't really figure out how to do it. Can you provide a step-by-step guide/video/whatever that shows how to sign the application, and what are the options (e.g to sign it without the store). Thanks.

Hello everyone, I am aware this has been asked quite a few times, but here we go: I am trying to get user JWT from https://appleid.apple.com/auth/token by sending a POST request via cURL in the following format (as specified at https://developer.apple.com/documentation/sign_in_with_apple/generate_and_validate_tokens ): curl -v POST "https://appleid.apple.com/auth/token" \ -H 'content-type: application/x-www-form-urlencoded' \ -d 'client_id=CLIENT_ID' \ -d 'client_secret=CLIENT_SECRET' \ -d 'code=CODE' \ -d 'grant_type=authorization_code' \ Where client id is my bundle id, code is random, client_secret is generated via the ruby script that is circulating the web: require 'jwt' key_file = 'testkey.p8' team_id = '...' client_id = '...' key_id = '...' ecdsa_key = OpenSSL::PKey::EC.new IO.read key_file headers = {   'kid' => key_id } claims = {     'iss' => team_id,     'iat' => Time.now.to_i - 86400,     'exp' => Time.now.to_i + 2*86400,     # 'exp' => Time.now.to_i + 86400*180,     'aud' => 'https://appleid.apple.com',     'sub' => client_id, } token = JWT.encode claims, ecdsa_key, 'ES256', headers puts token Ignore the timestamps, Ive been trying to play around with it quite a bit. I would expected the error "invalid_grant", alas Im getting "invalid_client" My flow to create the app: I registered an App ID under indetifiers, then I registered private key under keys for the created app, I also checked Sign In with Apple for both. I tried this for the original app, where the generated key was older than 48 hours (some said it might take a while for apple to consider the key valid). I also created a new app, where the key was just created, so Im going to try it in a few hour. Athough at the moment, its still invalid_client error. What I tried so far (might forget a few): Playing around with iat and exp fields for client_secret generation sending user-agent header as well generating client_secret via php (firebase/jwt) and ruby Also for the architecture: I have iOS app that hits laravel (php) backend and gets user token in the end, but fails on the very first step. Ive moved to using cURL to avoid any unexpected problems and would be extremely happy if I managed to get the error "invalid_grant" via cURL. Any help or insights would be highly appreciated!

I'm planning to transfer my app that uses Sign in with Apple from one development team to another (both are mine). I read https://developer.apple.com/documentation/sign_in_with_apple/transferring_your_apps_and_users_to_another_team and https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team but still don't understand what the migration process should look like. At first I thought that I could exchange the identifiers for all my users on my backend's side (using /auth/usermigrationinfo), right after the transfer is completed. The problem I see is that in this case my app won't be informed about the new user identifier. I store it in a device's Keychain because I need it later to check the credential state via https://developer.apple.com/documentation/authenticationservices/asauthorizationappleidprovider/3175423-getcredentialstate. If I've understood correclty, this method, called with the "old" user identifier param, after 60 days, starts returning an error or the notFound state. So I have to update this at some point. Okay, the second idea is to re-log silently all my users when they run my app after the transfer (as described at the bottom of this article: https://developer.apple.com/documentation/sign_in_with_apple/bringing_new_apps_and_users_into_your_team). But I can see another problem in here: someone may not run my app within 60 days. How should I approach this problem? I think this can be quite a common issue for a lot of developers. Thomas

When I migrate from team A to team B, is it possible that the sub in team A and the sub in team B overlap? For example, after the migration is completed, the sub of a user in team B is 820417.faa325acbc78e1be1668ba852d492d8a.0219. Will 820417.faa325acbc78e1be1668ba852d492d8a.0219 be the sub of another user in team A before the migration?

As stated in the title, the Apple Sign In view is showing the ipa file name instead of the app name on iOS 15.4.1, unlike on previous versions when it would show the app name. It doesn't happen on any older versions, just on iOS 15.4.1. Has anyone else encountered this? Is there a way to fix/workaround it?