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?

Hello. I have issue with implementing "Sign in with Apple" on my website. As folow, I have created: App ID identifier: com.livnobus.app (G2F5N5UHYZ) Service ID identifier: com.livnobus.client (B25ZN8P84U) with option enabled "Sign in with Apple" and configuration (Primary App ID and Webiste URLs) Key ID: 43N8XKUW7S with option enabled "Sign in with Apple" and configuration (Primary App ID and Grouped App Ids) When I click "Sign in with Apple" on my website (https://dev.livnobus.com/auth/login), system redirect me to https://appleid.apple.com/ and error show "invalid_client". Redirect URL on my web site is: https://appleid.apple.com/auth/authorize?client_id=com.livnobus.client&redirect_uri=https%3A%2F%2Fdev.livnobus.com%2Fauth%2Fapple%2Fcallback&scope=name%20email&response_type=code&response_mode=form_post&state=eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO&nonce=e7c7a242-1977-47ea-9013-98820c24bfba.eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO There was old Service ID identifier com.livnobus.app-client, for which I lost private KEY, so I have created new one: com.livnobus.client With old Service ID com.livnobus.app-client, https://appleid.apple.com/ shows me Apple form for sign in, but with new Service ID com.livnobus.client there is error "invalid_client" https://appleid.apple.com/auth/authorize?client_id=com.livnobus.app-client&redirect_uri=https%3A%2F%2Fdev.livnobus.com%2Fauth%2Fapple%2Fcallback&scope=name%20email&response_type=code&response_mode=form_post&state=eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO&nonce=e7c7a242-1977-47ea-9013-98820c24bfba.eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO These changes I have made last Friday, and since then I can't use "Sign in with Apple" on my website. Thanks!

I am having trouble with one of my apps that will not let me log in via Apple Sign In. I am using Firebase and Firebase UI for the sign in process. I have many other apps with the same exact config that currently work just fine, but this one I have gone as far as completely deleting the targets and rebuilding and it will not return from the login screen I checked the following: Sign in with Apple ID Capability is available in XCode and on the dev certificate on developer.apple.com I have also toggled both of them on and off. I have double checked the config in Firebase to turn on the Apple Login identifier. Again I have toggle it on and off. I have cleaned the project multiple times to no avail. I have logged out and back into my developer account in XCode. It seams like after I put in the correct password to log in, it just never returns to the app, there is no logging. I do get a notified(shaking input box) if I put in an incorrect password, but when I put in the correct one, the login window never dismisses and my app is not notified. I checked the Console and the last message from akd on a working app is: Notifying client (bundle) of credential state change 1. Remote view sent a finish event On the one not working, using the same user and password akd returns: SRP authentication with server failed! Error: Error Domain=com.apple.AppleIDAuthSupport Code=2 "M2 missing (bad password) I have 100% verified I am putting in the correct user password. I was only notified of this issue because Policy is having the same issue logging in during App Review. Also, if I put in a bad password the input window shakes and when this is happening, the input window is not shaking

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

Our app uses Sign in with Apple. In recent weeks (or months), we've noticed that emails sent to @privaterelay.appleid.com addresses are not being delivered. We're not receiving any bouncebacks or error messages from the mail server, but the emails never reach the user's mailbox. We've also checked spam folders, with no luck. We have verified that our Email Sources are configured correctly in Apple Developer settings. Is there any way to debug or trace what might be happening with these messages? Thanks in advance!

Hi Community, We've implemented Sign In with Apple in our application. Our domains are properly registered in the developer console, but we're experiencing inconsistent email functionality with Apple's privacy email service. Some domains work correctly while others show delivery problems, even though all domains have identical configurations. Apple's console displays green verification status for all domains, yet testing reveals that emails to privacy-protected accounts don't arrive as expected. We're using SendGrid as our email service provider, and all domains have valid authentication records (SPF, DKIM, DMARC) in place. Has anyone encountered similar inconsistencies with Apple's privacy email service? Would appreciate any configuration tips or troubleshooting guidance. Thanks.

Our app (app1) was recently transferred from Team A to Team B. While reviewing the Apple login implementation, we discovered that "Sign in with Apple" had been incorrectly set up to use the Service ID and App ID of another app (app2) — specifically, it was using app2.service as the Service ID and app2 as the App ID. In other words, app1’s users were authenticated through app2’s credentials due to a misconfiguration on our part. Now that app1 has been transferred to Team B, we’re trying to preserve those users. However, app2 is still in Team A, and we cannot maintain Team A anymore — meaning app2 must also be transferred to Team B if we want to retain access to the user data. One idea we considered is submitting app2 for App Review (even though it's non-functional) just to fulfill the transfer requirements, and then transferring it to Team B solely to retain the Apple login setup. Is this approach acceptable? Are there any recommended ways to handle this kind of misconfiguration while preserving existing Sign in with Apple users?

My existing iOS app has a legacy App ID prefix which does not match my Team ID. I am planning on migrating it to my Team ID. I am aware of the potential issues with keychain access groups, however I wanted to double check that there are no issues related to "Sign in with Apple". My app is currently the "Primary App ID" in the "Sign in with Apple" settings. The full App ID is listed there, including the prefix. Can someone from the relevant team at Apple confirm that changing the App ID prefix to Team ID has no effect related to "Sign in with Apple"?

We implemented a feature to receive name and email address after Sign in with Apple, and it works perfectly in our testing. However, during the app review, they says it doesn't work, and the app is rejected. Why does it work differently?

I keep getting invalid_client, here is a test login: https://www.bella-booking.ch/_get_incl/test_apple_login.cfm Any help appreciated. NOTE: Everey other error, like wrong reroute or wrong client id, a different error will be sent frpm apple, after I checked all and crosschecked with jwt.io, it keep getting invalid_client. Any clue? If the response is correct, the token should be displayed on the page. Thx

Hi! I'm trying to add Sign in with Apple to my macOS app. I enabled this capability from the developer portal and created the corresponding certificate & provisioning profile (both of type Developer ID Application.) However, Xcode keeps prompting me that the profile doesn't support Sign in with Apple. If I enable Automatically manage signing from Xcode, I can build and run the app but not distribute. If I turn it off and use the profile I got, it just keeps showing the errors below and doesn't even let me build.

Our organization operates a web platform that hosts numerous newspaper properties. We recently acquired a new newspaper and are in the process of integrating it into our platform. As part of this transition, we’ve successfully transferred the App and App ID for the acquired newspaper into our Apple Developer portal. However, no Service ID associated with Sign in with Apple was included in the transfer. Our current implementation uses a single, unified Service ID for all existing newspaper properties. This Service ID facilitates OAuth via a centralized Identity Server. The organization we acquired provided a CSV file containing a list of transport_ids, and based on our understanding, we’re expected to use the Apple endpoint: https://appleid.apple.com/auth/usermigrationinfo to initiate a registration process by submitting our Service ID (client_id) along with each transport ID. This step is required before users can sign in, and it should return the existing relay email address. We have a few key concerns: Service ID Compatibility It appears that users cannot be transferred between Service IDs. In our case, there are now two: a.) Our existing Service ID (used across all current newspaper properties) b.) A separate Service ID previously associated with the acquired newspaper 3.) Due to architectural constraints, our platform cannot dynamically toggle between multiple Apple Service IDs. All properties authenticate through our unified Identity Server bound to our existing Service ID. 4.) Is it possible to call /usermigrationinfo using our existing Service ID rather than the one originally used by the acquired property? 5.) Relay Email and Apple ID Consistency 6.) We’re seeing conflicting information about whether the Apple relay email address (@privaterelay.appleid.com) and the Apple user ID are preserved during this migration. Some sources suggest that the relay email and Apple ID are tightly coupled to both the Service ID and Team ID. 7.) If we call /usermigrationinfo with our existing Service ID, will the same relay email be returned, or will Apple issue a new one?

Please provide a descriptive title for your feedback: Downloading Developer ID provisioning profiles - missing new entitlements Which area are you seeing an issue with? App Store Connect What type of feedback are you reporting? Incorrect/Unexpected Behavior Please provide the App name/App ID if possible: com.onexengineering.themedeck.macos Please describe the issue and what steps we can take to reproduce it bug in App Store Connect where downloading Developer ID provisioning profiles are missing the new entitlements regenerated from scratch -- App Store Connect says entitlements are good, but actual file confirms entitlements are missing App Store provisioning profiles seem to be unaffected (ignore my incorrect naming of files)

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

Hello. Some of my users are signing in using "Sign in with Apple" and choosing the "Hide My Email" option. As expected, Apple generates a private relay email address. However, emails that we send to these addresses are not being delivered — the users report that they are not receiving anything. We’ve configured our email sending domains in the Apple Developer portal, and all domains have been successfully verified with SPF records marked as OK. Our system is sending the emails as usual, and we're not receiving any bounce-back or error messages. Everything looks fine on our end. Is there something specific we need to configure to ensure emails sent to privaterelay.appleid.com addresses are delivered correctly? Are there any known limitations or additional requirements for using Apple's private relay service? Thank you!

Dear Sir or Madam, Thank you for your continued support. My name is Sato from atmos. We are currently working with a vendor to implement Apple Sign In as a login method for our app, but we are encountering some issues and would like to contact you about them. The Apple Sign In functionality itself is almost complete, but during verification, email relay is not permitted by Apple when Apple Sign In is used with a non-public email address, making it impossible to complete email relay verification for users. We have reviewed the settings in “/account/resources/services/configure,” checked your FAQ, and explored all other possible solutions within our scope, but the situation remains unchanged. Would it be possible for your team to confirm the cause of the email relay not being permitted? Thank you for your assistance. atmos Sato Translated with DeepL.com (free version)

Hello, We’ve resumed the migration process after a break. Since my colleague is no longer with us, I had to go through the steps again myself. As before, we’re trying to migrate "Sign In with Apple" users from tenant TENANT_A with client_id=CLIENT_ID_A to tenant TENANT_B with client_id=CLIENT_ID_B I followed the procedure described here: [Apple Developer Documentation](https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer – Migrating Sign In with Apple Users, essentially repeating what my coworker previously attempted in coordination with your employee Stephanie. Here’s a summary of the steps and the issue we’re facing: STEP 1 - get authcode for TEAM A curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=pl.CLIEND_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' I receive response: { "access_token": "<ACCESS_TOKEN_TEAM_A>", "token_type": "Bearer", "expires_in": 3600 } STEP 2 - get authcode for TEAB B curl --location 'https://appleid.apple.com/auth/token' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode 'scope=user.migration' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAB_B_SECRET>' I receive response: { "access_token":"<ACCESS_TOKEN_TEAB_B>", "token_type": "Bearer", "expires_in": 3600 } STEP 3 - get transfer_sub from TEAM A curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_A>' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_A' --data-urlencode 'client_secret=<TEAM_A_SECRET>' --data-urlencode 'sub=USER_SUB_FROM_TEAM_A' --data-urlencode 'target=TENANT_B' I receive response: { "transfer_sub": "USER_SUB_FROM_TEAM_B" } STEP 4 - Team B exchanges transfer identifers curl --location 'https://appleid.apple.com/auth/usermigrationinfo' --header 'Authorization: Bearer <ACCESS_TOKEN_TEAM_B' --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'client_id=CLIENT_ID_B' --data-urlencode 'client_secret=<TEAM_B_SECRET>' I receive response: { "error": "invalid_request" } We’ve created a new client_id under tenant B and want to migrate users there. However, we skipped the step described in Step 3 of the documentation(https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer#3-Team-A-initiates-app-transfer-to-Team-B), which involves initiating an app transfer. The reason is that this client_id is used solely for web authentication, not for a mobile app, so we don’t have an app to transfer. Based on our analysis and your documentation, it seems this flow only works if the client_id matches across both tenants, which can only be achieved through an app transfer, something we cannot proceed with. Apple previously insisted that we migrate these users, but as shown above, we’re stuck. Is there any alternative flow available, or can you assist us in completing this migration?

As I had mentioned earlier, I was facing two issues after the initial update, but I’m happy to inform you that both of those issues have now been resolved. However, after updating to iOS 26.0 (23A5297m), I’ve started experiencing a new issue related to overheating. Since yesterday, my iPhone has been getting extremely hot while charging. It also became very hot after clicking just a few photos. The same heating issue occurred again today during charging. This problem only started after the latest update. Kindly look into this issue and advise on how to resolve it.