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.

Hi, Please see TN3159: Migrating Sign in with Apple users for an app transfer for more information on the expected end-to-end app transfer and user migration flow. Additionally, if you'd like for the iCloud and App Store engineering teams to confirm if the errors are related to a revoked authorization to previous users accounts, please submit a report via Feedback Assistant and include the following information: Gathering required information for troubleshooting Sign in with Apple user migration To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. For issues occurring with your user migration, ensure your feedback contains the following information: the primary App ID and Services ID the client secret for the transferring team (Team A) and the recipient team (Team B) the failing request(s), including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit via Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, Before I begin my investigation, I want to explain our code-level support process for issues related to Sign in with Apple—as the issue you’re reporting may be the result of any of the following: An error in your app or web service request. A configuration issue in your Developer Account. An internal issue in the operation system or Apple ID servers. To ensure the issue is not caused by an error within your app or web service request, please review TN3107: Resolving Sign in with Apple response errors to learn more about common error causes and potential solutions when performing requests. If the technote does not help identify the cause of the error, I need more information about your app or web services to get started. To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. Gathering required information for troubleshooting Sign in with Apple authorization and token requests For issues occurring with your native app, perform the following steps: Install the Accounts/AuthKit profile on your iOS, macOS, tvOS, watchOS, or visionOS device. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS, macOS, tvOS, watchOS, or visionOS device. Create a report in Feedback Assistant, and ensure your feedback contains the following information: the primary App ID or Bundle ID the user’s Apple ID, email address, and/or identity token the sysdiagnose gathered after reproducing the issue the timestamp of when the issue was reproduced screenshots or videos of errors and unexpected behaviors (optional) For issues occurring with your web service, ensure your feedback contains the following information: the primary App ID and Services ID the user’s Apple ID, email address, and/or identity token the failing request, including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, Before I begin my investigation, I want to explain our code-level support process for issues related to Sign in with Apple—as the issue you’re reporting may be the result of any of the following: An error in your app or web service request. A configuration issue in your Developer Account. An internal issue in the operation system or Apple ID servers. To ensure the issue is not caused by an error within your Private Email Replay configuration, please review Configuring your environment for Sign in with Apple to learn more about registering your email sources and authenticated domains. To prevent sending sensitive message details in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. Gathering required information for troubleshooting Private Email Relay with Sign in with Apple For issues occurring with your email delivery, ensure your feedback contains the following information: the primary App ID and Services ID the user’s Apple ID and/or email address the email message headers the Private Email Relay Service or Hide My Email message delivery failure, and SMTP error codes Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Running the sample "Juice" app, which demos the Sign In With Apple flow, doesn't seem to work with Xcode 12 beta and iOS 14 beta on the simulator (worked fine on the non-beta versions and on a real device with iOS 14 beta). Once the password for the device's Apple ID is entered, the wheel in the password field just keeps spinning. No error messages and nothing handed back over to the app from the ASAuthorizationController. Anyone else seeing this problem ? Are there any workarounds ?

Sign up not completed when I log to an app using apple id. What should i do?

Hello, I'm trying to renew my Appstore Connect subscription but unfortunately I'm facing problems. Our Account Holder ID is locked and when he tries to log in an error message keeps showing up saying "This Apple ID has been Locked. Contact your Administrator or Manager to reset your password and unlock your account." whose the admin or manager in this case? I contacted the support multiple times and they referred me to this link. https://support.apple.com/en-us/HT201487 We tried these steps but sadly no luck. whenever he tries to change the password an error message keep popping up saying "Need to reset your password? Contact your organization’s Administrator or Manager and ask them to reset the password for your Managed Apple ID"

Hello, our Sign in with Apple Button no longer works and throws an 7003 error. It worked a few days ago but suddenly fails. Any ideas how to fix this? Thanks in advance! plist: <dict> <key>com.apple.developer.applesignin</key> <array> <string>Default</string> </array> ... Code: var body: some View { VStack { SignInWithAppleButton(.signUp) { request in request.requestedScopes = [.fullName, .email] } onCompletion: { result in switch result { case .success(let authResults): handleSuccess(authorization: authResults) case .failure(let error): self.credentialFailure = true self.errorMessage = .appleSignInError logger.error("SIWA login failure: \(error)") } } .signInWithAppleButtonStyle(.white) .cornerRadius(GlobalValues.cornerRadius) } } Error: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.our.app} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" SIWA login failure: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)"

Hi, I run a midsize business. Apple recommends for company owned devices and for other reasons to use Apple Business managed Apple IDs for the employees. After that, you have to use a MDM System for e.g. deploying apps and licenses. Testflight is an app that can be deployed too. But....Testflight can not more than to say "Hello" on a managed device. The use of Testflight and to test our developed apps is not possible with a managed ID. Can anyone explain to me this thinking or what is recommended than. Setting up a private Apple ID for that purpose...which on the other hand, Apple do not want or does not recommend.

Hello I have a problem with provisionprofile file. I have created Identifier with Sign in with Apple capability turned on, created Profile with Developer ID selected and now I try to export archive with generated Developer ID provision file but it says "Profile doesn't support Sign in with Apple" Also interesting thing that default provisions like macOS App Development Mac App Store Connect don't show such error when I try to export archive Maybe this problem is only related to Developer ID provision and Direct Distribution doesn't support Sign in with Apple, but I havent found proves about this idea

I've just implemented Sign-In-With-Apple and everything is working perfectly, but my app seems to be in some strange state where users are unable to remove it from the Sign-In-With-Apple section of their settings. Things I've tried: -- Deleting from Mac. (It just stays in the list) -- Deleting from the iPhone (It stays in the list) -- Deleting from account.apple.com (same issue) -- I've noticed in the browser inspector tools I receive a 200 on the DELETE request, but the app remains. -- Multiple users Also have tried: -- Revoking the token through the REST API -- I get an email saying the token has been revoked, but it's still working -- Same code, different app id (works fine!) It seems like maybe my app is in some sort of weird state? Has anyone come across this before?

I am getting the following errors. The app used to work and now does not, even without any code changes. Any thoughts on resolving this issue? Authorization failed: Error Domain=AKAuthenticationError Code=-7026 "(null)" Us erInfo={AKClientBundleID=<bundleid>} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" Us erInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" Us erInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)"

I’ve been running into an issue for over a day when trying to create a Sign in with Apple key. Each time I attempt to download it, I’m redirected to a page that displays an error and provides no further guidance. I’ve contacted Support and haven’t yet received a reply. I’ve also tried across multiple browsers (Chrome, Safari, Firefox), including incognito modes. Any ideas on how to resolve this? We’re currently stuck and would appreciate guidance.

I'm currently transferring an iOS app to a new Apple Developer account and following the process outlined in Apple’s documentation: 🔗 TN3159 - Migrating Sign in with Apple users for an app transfer The process for generating transfer_identifiers and migrating existing users is clear, and I don’t expect issues with that part. However, I have a question about preserving the user session after the transfer. My setup: The app uses Sign in with Apple via a backend-based authentication flow. On login, the app retrieves the authorization_code and sends it to the backend. The backend exchanges the code for tokens from Apple, including a refresh_token. That refresh_token is then used on the backend to validate the user’s identity on subsequent requests. My concern: Once I initiate the app transfer, migrate users, and update the backend with new Apple credentials (client ID, team ID, etc.), I assume that the existing tokens issued under the old credentials will become invalid. So my question is: Is there a way to maintain the user’s authenticated session through this transition without requiring them to manually sign in again? I’d like to ensure a seamless experience for users, if possible.

Our iOS app uses Sign in with Apple to authenticate users, and we use Firebase for the backend — for both Auth and Storage. If anyone can provide guidance and/or share experience on how to migrate an iOS app to a different App Store Connect team, particularly with a Firebase backend, that would be fantastic. Below I'll provide info about our situation, and I'll describe what I understand so far about the migration process. About our app: A few months ago, we transferred our iOS app to a different App Store Connect team, and it seemed that everything was fine... but recently we learned that we should have migrated SIWA (Sign in with Apple) users so that Sign in with Apple will continue to work under the new team, but we didn't do that, and as a result of missing the 60-day window, Apple's documentation says that we now need to transfer the app back to the original team... and then we can start preparing to migrate the SIWA users to the new team. Before transferring back to the original team, we started receiving errors during the Sign in with Apple process which say "Sign Up Not Completed" in Apple's UI... but the callback authorizationController(controller:didCompleteWithError:) is NOT called. For reference, here's Apple's documentation on this subject: TN3159: Migrating Sign in with Apple users for an app transfer [https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer][2] Transferring your apps and users to another team [https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team][3] Bringing new apps and users into your team [https://developer.apple.com/documentation/signinwithapple/bringing-new-apps-and-users-into-your-team][4] Note: the first article contains 4 broken links (thanks Apple 🙄) but it's pretty clear that these 2 other links ☝️ are where those broken links should be pointing to. In our situation, it's clear that we need to transfer the app back to the original team. But how to proceed after that? As I understand it, for a given user, Apple provides a sub which is basically a user ID that is specific to that team. After the app is transferred to the new team, the sub returned from Apple will be different... but Firebase doesn't appear to store the sub anywhere, so it's either unimportant OR we need to set up our own Auth instead of using Firebase Auth. Thoughts? When using Sign in with Apple, the user's email address is exposed to our app... but if the user opted to use a private relay email address, that's a problem, because private relay email addresses are ALSO specific to that team. If the user with a private relay email tries to log in under the new team, we won't recognize their "new" email address, but we need a way to associate that user with their "old" account in Firebase. The solution provided by Apple is that we need to request the transfer_sub (also known as a "transfer identifier") for each user, and we need to store the transfer_sub in our backend to be able to allow a user who is logging in under the new team to still have access to their "old" account in Firebase. Even though private email relay addresses and subs will be different under the new App Store Connect team, the transfer_sub is the same for each user across both teams. According to Apple's documentation, the user's sub is needed in order to request the transfer_sub... but if we're not already storing the sub in Firebase, then how do we request the sub for every user, then the transfer_sub for every user, and then store that info in Firebase? Does this need to happen on the iOS side? And what would happen to a user who was using our app for months, then stopped using the app for >60 days while we were doing the migration, and then tried to sign in again? Will that user be permanently be locked out of our app? Is it impossible to keep all users happy and able to log into their accounts in this scenario? TLDR: We're trying to migrate an iOS app with a Firebase backend (Auth and Storage) to a different App Store Connect team... and it's apparently a complicated process because we're using Sign in with Apple. Please help if you can! Thank you! 🙏

Dear Apple Support Team, I hope this message finds you well. Our tech team is currently working on integrating the Apple Sign-In feature, and we have a specific query where we would appreciate your guidance. Background Context: We have several applications across different brands and are aiming to implement a unified sign-up and sign-in experience. Currently, we are utilizing a shared website to enable single sign-in functionality across all these applications. Our Query: If we embed the same website in all of these applications and implement the Apple Sign-In within this website—using a dedicated Service ID that is configured with the App Store name and icon—will users consistently see the Apple Sign-In pop-up with the Service ID’s name and icon, regardless of which base application (e.g., App A, App B, etc.) the website is accessed from? We would like to ensure a seamless and consistent user experience and want to confirm that the branding within the Apple Sign-In prompt will reflect the Service ID’s configuration, rather than that of the hosting app. Looking forward to your guidance on this matter.

"Failed to verify your identity. Try again." I only see this text. I have the correct apple account and password and I have made the payment. I can't log in with my password, why? Question 1: What should I do to log in with my password? Question 2: What is the error?

Hi Apple Developer Community, We have carefully reviewed the documentation on App Transfer and User Migration, but we still have a few unresolved questions regarding Apple Sign-In token behavior and testing strategies. Would appreciate any guidance! Token Behavior for Pre-Transfer App Versions After the app transfer: If a user logs in via an existing pre-transfer version of the app (published under Team A before transfer), will the Apple Sign-In token’s sub (or private email) switch to new value tie to Team B, or unchanged? This is critical for our user migration plan. Preserving sub Across Transfers (Internal Team Transfer) Since our app-transfer is an internal transfer (no change in app ownership outside our organization), is there a way to retain the original sub value（or private email） for users after the transfer? We are concerned that Apple Sign-In errors during the app transfer process may negatively impact user experience. Testing the Transfer Process Safely We’d like to simulate the app transfer and user migration process in a sandbox/test environment before executing it in production. Is there a way to test app transfers without affecting live users? (e.g., a staging mode for transfers) Thank you for your expertise! Any insights would be invaluable.

Hi everyone, My web application has two services: myapp.com and account.myapp.com. The first manages all app content, while the latter handles the authentication, with Sign In with Apple included. The tech stack is mainly composed of React, JS, and Express. We'd like to allow users to authenticate inside a dialog on some pages of myapp.com. To avoid replicating stuff from one service to another, we put an iframe inside the dialog to show the authentication standard page from account.myapp.com. Email and Facebook processes work fine, but we have the following issues with Sign in with Apple: On desktop, not Safari, a pop-up window opens when you click on the Apple button, and it works as expected. On desktop Safari, the pop-up window is blocked. We want the native Apple pop-up to show instead of a generic browser new window. On mobile, nothing happens on click Obviously, outside the iframe, everything works as expected. I can't seem to find anything related to an iframe constraint in the Sign in with Apple docs. Is this feasible?

I am trying to create an AppId to support Sign in with Apple from my web app. This capability is not availability. An AI query suggests that this is not supported with an Enterprise account, though I cannot find any links/information to support this. Is this a known issue?

Hello, for applications using Signin with Apple feature, it seems a particular process needs to be followed when you want to transfer the app to a new owner. Generating transfer identifier before the transfer of ownership to identify a particular user. There is already "email" registered for the user, personal email or relay email (doesn't matter). Why would we need to trouble ourselves with the transfer identifier? The documentation doesn't explain anything about the background of this. It is very weak. It doesn't explain the impacts/changes when app is transferred so that one can fully understand its impact. Thank you.

I was experiencing a weird sign in error when using apple sign in with my app and wanted to put it here for anyone else who might experience it in the future, and so apple can make this requirement more clear. I was using CloudKit and apple sign in. If you are not using both this probably does not apply to you. Every time I would go to sign in in the iOS simulator I would enter my password, hit "sign in", and everything just froze. The very odd reason for this is if you are using iCloudKit and apple sign in you need to go to specifically the "identifiers" in the "Certificates, Identifiers & Profiles" menu (https://developer.apple.com/account/resources/identifiers/list). And from there you specifically need an App ID Configuration with apple sign in enabled. From there you have to have the same exact bundle identifier in Xcode under project settings(not an upper tab just click your project in the left panel). And that should allow you to both pass validation and have your sign in work. Hope this helps!

Hi, preivously on appleid.apple.com, navigating to this page on safari would show the in-app modal to continue with Apple. Now with account.apple.com, this is not the case. We are not seeing the in-app modal to continue with Apple