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

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

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?

Hello Apple Developer Community and Support, Our team is encountering a critical and persistent issue with our backend integration of Sign In with Apple, and we are hoping for some insights or assistance. Problem: We consistently receive an "invalid_client" error (HTTP 400 status) when our backend service attempts to exchange the authorization code for tokens at Apple's https://appleid.apple.com/auth/token endpoint. The error message from Apple's response is simply {"error":"invalid_client"}. Our Setup: Client Application: An iOS native application. Backend Service: A Go backend responsible for server-to-server token exchange and user management. Sign In with Apple Flow: The iOS app initiates the Sign In with Apple flow, obtains an authorization code, and then passes this code to our backend for token exchange. Extensive Troubleshooting Performed (No Success): We have meticulously followed all official Apple documentation (including TN3107: Resolving Sign In with Apple Response Errors) and industry best practices. Here's a summary of our verification steps, all of which currently show correct configurations and parameters: Backend client_secret JWT Construction: We generate a client_secret JWT as required for server-to-server communication. We've confirmed the claims in the generated JWT are correct: iss (Issuer): Our Team ID (e.g., XXXXXXXXXX). sub (Subject): Our Service ID (e.g., com.example.service.backendauth). aud (Audience): https://appleid.apple.com. kid (Key ID): The Key ID associated with our .p8 private key (e.g., YYYYYYYYYY). We have performed rigorous verification of the .p8 private key content itself, ensuring no corruption, extra characters, or formatting issues in the environment variable. Our backend logs confirm it's parsing the correct PEM content. Token Exchange Request Parameters: The client_id parameter sent in the POST request to /auth/token is correctly set to our App Bundle ID (e.g., com.example.app.ios), as this is the identifier for which the code was originally issued. The redirect_uri parameter sent in the POST request to /auth/token is precisely matched to a registered "Return URL" in our Apple Developer Portal (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Apple Developer Portal Configuration (Meticulously Verified): App ID: Enabled for "Sign In with Apple". Service ID: Enabled for "Sign In with Apple". Its "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). Its "Return URLs" exactly match our backend's redirect_uri (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Key: Our .p8 key has "Sign In with Apple" enabled. Crucially, in its configuration panel, the "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). We've ensured this key is specifically created for "Sign In with Apple" and not other services like APNs. We have performed multiple full revocations and meticulous re-creations of the App ID, Service ID, and Key in the Apple Developer Portal, ensuring correct linkages and using new identifiers to bypass any potential caching issues. Network & System Health Checks: Network connectivity from our backend server to https://appleid.apple.com (port 443) has been confirmed as fully functional via ping and curl -v. The incoming TLS handshake from our iOS client app to our backend server's callback URL (https://api.example.com:port/...) is successful and verified via openssl s_client -connect. There are no longer any TLS handshake errors (EOF). Our backend server's system clock is accurately synchronized via NTP. Request for Assistance: Given that all our visible configurations, environment variables, and request parameters appear to be correct and align with Apple's documentation, and network connectivity is confirmed, we are at a loss for why the invalid_client error persists. Based on TN3107, this error typically implies an issue with the client secret's signature or its validity for the given client_id. However, our logs confirm correct iss, sub, aud, and kid, and the private key content. Has anyone encountered this persistent invalid_client error when all checks pass? Are there any less common configurations or troubleshooting steps we might be missing? Could this indicate a caching or propagation delay on Apple's servers, even after waiting periods? Any insights or guidance would be greatly appreciated. We are prepared to provide detailed, anonymized logs and screenshots to Apple Developer Support privately if requested. Thank you.

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

My app was rejected from App Store because of the following reasons: This item has been rejected for the following reasons: 2.1.0 Performance: App Completeness 4.8.0 Design: Login Services I implemented and upgraded the app with these updates. However, the app is working fine on the test side, but it shows an error when I try to upload the app for review again. Please advise my next steps.

When implementing Sign In with Apple I created an App ID and a Service ID for my app. I didn't configure the Server-to-Server Notification URL properly there and token revocation didn't work. Later on I updated the url config and the name of the identifiers. However, when I Sign in with Apple in my app I still see the old identifier name in my iPhone Settings->Apple Account->Sign in with Apple. I would assume that if the name doesn't update, the configuration doesn't update either. I'm using automatic Xcode signing, I have deleted all the profiles locally, cleaned project, bumped versions, waited for a week, nothing worked. Token revocation for account deletion doesn't work properly I would assume because of the initial misconfiguration. I want to mention that this is working fine for my development build (another bundleID, AppID, ServiceID) What am I missing here?

I am trying to implement Apple Login on the web. The language I am using is PHP. I have created the App ID, Service ID, and Key. In the Service ID, I clicked the Configure button for Sign In With Apple and entered the domain and return URL. However, when I click the login button, I only get an "invalid_client" error screen.

Hello, I am at wits' end with the Apple Sign-in api. I have tested in stage and it works beautifully, but when i push to production it gives me the error "invalid_client". I'm confident the setup is correct, when I asked Apple for help over the phone, they sent me a few forums with no answers. Has anyone had the same issue? How did you resolve? Could it be because I have two app IDs and two service IDs? (prod + stage) Help!

We're integrating Sign in with Apple into our iOS app The Apple ID login UI appears correctly on real devices, but after tapping Continue, the system immediately stops and shows code 1001. This issue happens across multiple devices and Apple ID accounts, even with no prior login history. We’ve confirmed the following Sign in with Apple is enabled in both Developer Portal and Xcode Capabilities Automatic signing and provisioning are set correctly Device is signed into iCloud and system time is synced Performed clean build, app reinstall, and other standard debugging steps We suspect that the sign in handshake process may not be completing properly due to some kind of account or server-side restriction, and we’d appreciate any insights into this behavior.

We’re integrating Sign in with Apple using Apple’s official JavaScript SDK: https://appleid.cdn-apple.com/appleauth/static/jsapi/appleid/1/en_US/appleid.auth.js We’ve successfully used this setup with an older Service ID, but when we try to use any newly created Service ID, we get the following error immediately when calling AppleID.auth.signIn(): invalid_client This happens before any request reaches our backend. The same flow, redirect URI, and frontend code works fine with an old Service ID — but fails with new ones. ✅ What We’ve Verified: The Service ID (e.g., com.projectx.web.login) is created under Apple Developer → Identifiers → Service IDs The redirect URI is correct and matches exactly (HTTPS, no trailing slash) No client_secret is passed in the frontend (by design) We’re using usePopup: true ❌ What Doesn’t Work: Any new Service ID we create — even on the same domain and configuration — fails with invalid_client. 🔁 What We’ve Tried: Creating multiple new Service IDs Waiting 48+ hours in case of propagation delays Validating HTTPS and redirect URI setup Comparing all settings with the working (older) Service ID (which we deleted since we thought that was causing a problem) Testing in different environments and browsers ❓ Questions: Why do newly created Service IDs fail with invalid_client while older ones work? Are there undocumented requirements, propagation delays, or steps for new Service IDs to become active? Is this a known limitation or bug in the SDK? 💻 Our Code: import { useEffect } from "react"; import { Button, Box } from "@mui/material"; import api from "../utils/api"; // Axios wrapper import AppleIcon from "@mui/icons-material/Apple"; import MainAuthStyles from "../pages/MainAuthStyles"; import { useUser } from "../../../user-module/src/contexts/UserContext"; import { useNavigate } from "react-router-dom"; // Apple global type declare global { interface Window { AppleID: any; } } type AppleSignInButtonProps = { setApiError: (msg: string) => void; }; const AppleLogInButton = ({ setApiError }: AppleSignInButtonProps) => { const { user, setUser } = useUser(); const navigate = useNavigate(); useEffect(() => { if (!window.AppleID) return; window.AppleID.auth.init({ clientId: import.meta.env.VITE_APPLE_CLIENT_ID, scope: "name email", redirectURI: import.meta.env.VITE_APPLE_REDIRECT_URI, usePopup: true, }); }, []); const handleAppleLogin = async () => { try { const response = await window.AppleID.auth.signIn(); const { id_token, code, user } = response.authorization; const res = await api.post("/auth/apple-login", { idToken: id_token, code, user, rememberMe: true, }); if (res.data.success == true && res.data.user.userDataInitialised == true ) { setUser({ id: res.data.user.id ? res.data.user.id : '', fullName: res.data.user.fullName ? res.data.user.fullName : '', email: res.data.user.email ? res.data.user.email : '', role: res.data.user.role ? res.data.user.role : '', signUpType: res.data.user.signUpType ? res.data.user.signUpType : '', userDataInitialised: res.data.user.userDataInitialised ? res.data.user.userDataInitialised : false, }); localStorage.setItem("accessToken", res.data.accessToken); localStorage.setItem("refreshToken", res.data.refreshToken); navigate("/app") } else { setApiError("Unrecognized login method") return; } } catch (err) { console.error("Apple Sign-In failed", err); setApiError("AppleSignInFailed"); } }; return ( <Box mt={2}> <Button variant="outlined" fullWidth onClick={handleAppleLogin} className="AuthAppleButton" startIcon={<AppleIcon />} > Log in with Apple </Button> </Box> ); }; export default AppleLogInButton; Any help from the Apple team or anyone who's resolved this issue would be appreciated — we’re currently blocked on deploying new environments due to this error. Thanks!

I am implementing Apple Sign-In for a multi-platform application, specifically for the web component using the REST API flow. I am encountering an invalid_request Invalid web redirect url error when attempting to use a newly registered redirect URL. Here are the details: Original Test URL: I initially registered a redirect URL, let's call it [Your Original Test Redirect URL, e.g., https://test.yourdomain.com/auth/callback], for testing purposes. This URL worked correctly. New Service URL: I then registered a second redirect URL, [Your New Service Redirect URL, e.g., https://www.yourdomain.com/auth/callback], intended for my production service. This URL was registered approximately 5 days ago (including the weekend). The Problem: The new service URL ([Your New Service Redirect URL]) is still not working and consistently returns the invalid_request Invalid web redirect url error. Puzzling Behavior: Furthermore, I have since deleted the original test URL ([Your Original Test Redirect URL]) from the Service ID configuration in the Apple Developer portal. However, the deleted test URL still appears to function correctly when I use it. This situation is highly confusing: The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. The Service ID in question is [Your Service ID, e.g., com.yourdomain.service]. Could you please investigate why the new redirect URL ([Your New Service Redirect URL]) is not becoming active and is returning the invalid_request error, and also explain why the deleted URL ([Your Original Test Redirect URL]) remains functional? Any guidance or assistance you can provide to resolve this issue with the new URL would be greatly appreciated. Thank you for your time and support. Sincerely, I have the exact same problem. The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. In addition to the above problem, I also get a response of 'invalid_client' when I newly register a service in configuration. Please check it out as it needs to be resolved quickly.

Hi, I've been developing an app with a server. I'm hosting the server on an IPv6-ONLY network that's hidden behind the CloudFlare, so it works flawlessly from the clients point of view, but if server needs to access external resources, they need to be accessible over IPv6. As it turns out, appleid.apple.com doesn't support IPv6, and the Sign In with Apple happens with the help of my server. So, I can't sign users in as Apple doesn't support IPv6 traffic on appleid.apple.com. Are there any plans to support IPv6 in the near future, or should I work on the networking setup to enable IPv4 just for the Apple SSO? Or maybe there's a clever workaround I'm missing?

On Thursday, June 12, 2025, Sign in with Apple was impacted by an incorrect subdomain defined in its /.well-known/openid-configuration file. The JSON returned incorrectly provided https://account.apple.com instead of the expected https://appleid.apple.com. For Sign in with Apple, the value for the issuer (iss) claim in the user's identity token is https://appleid.apple.com. Additionally, if your clients use the Sign in with Apple REST API, the following endpoints should be used for each request: https://appleid.apple.com/auth/authorize https://appleid.apple.com/auth/token https://appleid.apple.com/auth/revoke https://appleid.apple.com/auth/keys This issue with the /.well-known/openid-configuration file was resolved the same day. Use the URL below to confirm the expected subdomain is provided, as needed: https://appleid.apple.com/.well-known/openid-configuration Cheers, Paris X Pinkney |  WWDR | DTS Engineer

On Wednesday, June 18, 2025, Sign in with Apple was impacted by a configuration issue which affected some developer accounts that created new app or Services ID configurations, or edited existing configurations, resulting in the following errors: invalid_client response error returned by the authentication, token validation/revocation, and user migration requests "Sign Up Not Completed" (or equivalent) error presented from the Authentication Services framework. On Monday, June 23, 2025, this issue was resolved. Please retry the Sign in with Apple flows in your Sign in with Apple enabled apps and websites to confirm your developer account configuration has been fixed. Please let us know if you can still reproduce this issue with your developer account. If so, follow the steps outlined in the post below: Gathering required information for troubleshooting Sign in with Apple authorization and token requests https://developer.apple.com/forums/thread/762831 Finally, reply (not comment) with your Feedback ID on either of the posts below: https://developer.apple.com/forums/thread/789011 https://developer.apple.com/forums/thread/789132 Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi Apple Developer Support, We are implementing Sign in with Apple for our web application hosted on example.com. In the Service ID settings, we have configured the following: Service ID (client_id): com.example.service.local Web Domain: example.com Return URL: https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple We also tested login via the following URL from our web application: https://appleid.apple.com/auth/authorize?response_mode=form_post&response_type=code&client_id=com.example.service.local&scope=name%20email&state=2f9gMY1rTe12-O7Wbnb7KWe504HQ0KWBSHTKHbg9ZEY=&redirect_uri=https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple However, we’re receiving an invalid_client error after submission. Our questions: Is it valid to use an ngrok URL like https://2db2-121-160-153-88.ngrok-free.app/... as the Return URL for development and testing? Does the Web Domain need to match the ngrok domain, or is it enough to register the production domain (e.g., example.com)? Is there any propagation delay or approval process after updating the Return URL in the Service ID? Is the client_id strictly required to match the Service ID exactly? We would greatly appreciate any insights or best practices to help us resolve this issue. Thank you in advance!

Dear Apple Developer Technical Support, We are currently following the official Apple documentation “TN3159: Migrating Sign in with Apple users for an app transfer” to carry out a Sign in with Apple user migration after successfully transferring several apps to a new developer account. Here is a summary of our situation: Under the original Apple developer account, we had five apps using Sign in with Apple, grouped under a shared primary app using App Grouping. Recently, we transferred three of these apps to our new Apple developer account via App Store Connect. After the transfer, these three apps are no longer associated with the original primary App ID. We reconfigured individual Services IDs for each app in the new account and enabled Sign in with Apple for each. More than 24 hours have passed since the app transfer was completed. Now we are attempting to follow the migration process to restore user access via the user.migration flow. Specifically, we are using the following script to request an Apple access token: url = "https://appleid.apple.com/auth/token" headers = {"Content-Type": "application/x-www-form-urlencoded"} data = { "grant_type": "client_credentials", "scope": "user.migration", "client_id": "com.game.friends.ios.toptop.sea", # New Services ID in the new account "client_secret": "<JWT signed with new p8 key>" } response = requests.post(url, headers=headers, data=data) However, the API response consistently returns: { "error": "invalid_client" } We have verified that the following configurations are correct: The client_secret is generated using the p8 key from the new account, signed with ES256 and correct key_id, team_id, and client_id. The client_id corresponds to the Services ID created in the new account and properly associated with the migrated app. The scope is set to user.migration. The JWT payload contains correct iss, sub, and aud values as per Apple documentation. The app has been fully transferred and reconfigured more than 24 hours ago. Problem Summary & Request for Support: According to Apple’s official documentation: “After an app is transferred, Apple updates the Sign in with Apple configuration in the background. This can take up to 24 hours. During this time, attempts to authenticate users or validate tokens may fail.” However, we are still consistently receiving invalid_client errors after the 24-hour waiting period. We suspect one of the following issues: The transferred apps may still be partially associated with the original App Grouping or primary App ID. Some Sign in with Apple configuration in Apple’s backend may not have been fully updated after the transfer. Or the Services ID is not yet fully operational for the transferred apps in the new account. We kindly request your assistance to: Verify whether the transferred apps have been completely detached from the original App Grouping and primary App ID. Confirm whether the new Services IDs under the new account are fully functional and eligible for Sign in with Apple with user.migration scope. Help identify any remaining configuration or migration issues that may cause the invalid_client error. If necessary, assist in manually ungrouping or clearing any residual App Grouping relationships affecting the new environment. We have also generated and retained the original transfer_sub identifiers and are fully prepared to complete the sub mapping once the user.migration flow becomes functional. Thank you very much for your time and support!

Our app ID is 708064914; When we transferred an app with Sign in with Apple function, and request the REST API to get transfer_sub, approximately 25% of the requests return error responses such as: {"error":"invalid_request","error_description":"User not found."} or {"error":"invalid_request"} User 001700.6b50fa0cdf564b4f83e3ac6b8dfb9a9b.1205 received the first error; User 000908.523b85e1dd704d808dbfac55425c5a7b.1916 received the second error. Here's the English translation: We want to understand under what circumstances these errors occur. Since we have already transferred once before, this is the second transfer. The "User not found" error might be related to IDs from the original team. However, we don't understand the meaning of the second error type and what circumstances might cause it.

Our app ID is 708064914; When we transferred an app with Sign in with Apple function, and request the REST API to get transfer_sub, approximately 25% of the requests return error responses such as: {"error":"invalid_request","error_description":"User not found."} 001307.dba0ea2b147f45aa9e85de2abfb4c072.2047 received the first error; We want to understand under what circumstances these errors occur. Since we have already transferred once before, this is the second transfer. The "User not found" error might be related to IDs from the original team. Is that right?