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!

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

Need assistance in implementing this device management feature. Our free plan lets each person use one special device. To make this work, we need to set up device control right after they log in. Because of this, we can’t let people use our app on more than one device or platform at the same time. If we don’t ask them to log in, we won’t know if they have already used their free device on Android or the Chrome extension. But Apple wants us to give people free access to things that don’t need an account. Can you help us find a way to do this?

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

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.

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

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.

News link: https://developer.apple.com/news/?id=12m75xbj If your app offers Sign in with Apple, you’ll need to use the Sign in with Apple REST API to revoke user tokens when deleting an account. I'm not good English. I'm confused about the above sentence Do I have to use REST API unconditionally or can I just delete to the account data?

Our app got rejected with below reason Your app offers Sign in with Apple as a login option but does not follow the design and user experience requirements for Sign in with Apple. Specifically: Your app requires users to provide their name and/or email address after using Sign in with Apple. This information is already provided by the Authentication Services framework. These requirements provide the consistent experience users expect when using Sign In with Apple to authenticate or login to an account. We have an option to login to our app with Apple sign in The user must have a valid account with a valid email id, that created from the web and the user must complete all onboarding program In the app once the user sign-in using Apple login, we will check for the email ID is hidden or not, if it is hidden we cant log in because we must have a valid email id. So we show a modal with " We can't log you in because your email is hidden. Please select "Share My Email" to continue or use the regular email login option" If user shares an email, then will check for account exists for that email or not,if yes, it will allow to log-in to the app How can I sort out this problem?

We have 2 developers: Developer A created a Bundle ID and configured Sign in with Apple, but didn't create a corresponding App. This Bundle ID is only used for login on our official website. Developer B created a Bundle ID, configured Sign in with Apple, and has a corresponding App. The issue we're encountering is that because these two Bundle IDs are under different teams, when using the same Apple ID to log into these two applications, different accounts are generated. (We've tested that when creating Service IDs under the same team, logging in with Bundle IDs under the same team generates the same account.) Since Developer A's Bundle ID doesn't have a created app, it cannot be transferred to Developer B. Therefore, we'd like to know if there's any way to make the accounts generated from logging in with the same Apple ID be identical across these two teams?

In response to inquiries from users, we have confirmed the following phenomenon. If you select "Private email address" in the flow of new user registration with Apple ID, you will not receive the verification code email when performing two-factor authentication. ■User impact If you use your Apple ID to link an external account without making your email address public, you will not receive the authentication code during two-factor authentication and will not be able to proceed. The date and time of the impact is currently unknown. ◎Impact 1: New registration If you select "Private email address" in the flow of registering a new user with Apple ID, the verification code will not be received during two-factor authentication and registration will not be completed. ◎Impact 2: Login of existing account When two-factor authentication is required for an existing account registered with Apple ID set to "Private email address," the verification code is not received and the user cannot log in. →If you have not registered a login method other than Apple ID for the relevant account, there is no other way to log in. ■About workarounds ・I thought that I could avoid this issue by canceling the private setting of my Apple ID, but I was unable to do so. →There is currently no workaround found for existing users who are experiencing this issue. ・However, the scope of influence is limited. ■Cause investigation status Premise: For an Apple ID whose email address is not made public, the two-factor authentication authentication code email follows the following route. ①CDC/GIGYA miraiz-persol.jp (SendGrid) Apple's email server (relay server to hide the user's real email address) User mailbox →Since '1' are working, the problem seems to have occurred after the connection from ② or ③. (At this stage, we cannot determine who is at fault: the user, MIRAIZ, or Apple. We are currently investigating.) ◎Hypothesis ・Is there something wrong with Apple's mail server? ・Is it not delivered because the user's mailbox is full? ■Questions, research, and responses we would like to receive Please check the following two points and reply. 1st point As shown in the attached image, there seems to be no problem with the SPF settings. Is it possible to check to see if any errors have occurred with Apple's mail server? 2nd point Are there any cases where you still can't receive emails even if you deactivate your Apple ID? I would like to know if there are any patterns in which emails are not being delivered in terms of past inquiries or overall specifications

Hello We would like to proceed with the transfer of ownership of the launched app based on the Cafe24 platform.(Web App) Last month, I inquired about how to transfer the Apple account login function together when transferring ownership and received a related manual. When I asked and inquired about help from several developers regarding that part, they all received different answers. Please review the answers below, and I would really appreciate it if you could guide me on how to proceed. Developer 1: Cafe24-based launch apps require a separate transfer of the login function. It does not affect if you do not delete the existing member data in the database, and you only need to activate the login function to the new developer account. Developer 2: Checking and analyzing existing servers and data - Transfer user data to Apple using Apple's Legacy User Identifier - Synchronize user data - Test and modify It has to proceed to the above four steps, and synchronization work is also required to maintain all of the existing user's data because all of the user's identification values change when the login function is transferred. Developer 3: It appears to be a task that needs to be stored in the server database by migrating from the user identifier created in the existing developer account to the user identifier to be used in the new developer account, which is not what the app is supposed to do, and it is recommended to find other experts. Thank you.

Hello Apple Developer Community, We are experiencing an issue with email delivery when users sign in using "Sign in with Apple" on our platform. We need assistance in understanding and resolving this problem. Issue Description: When users choose to hide their email during the "Sign in with Apple" process, Apple provides a private relay email address (e.g., xxxx@xxx). These private relay email addresses are successfully received and stored in our system via the OIDC protocol implemented on Keycloak. Verification emails are sent from our configured email address to the private relay email addresses. However, users do not receive these emails, and we suspect they are not being forwarded to the user’s actual email address. Steps Taken: Sender Address Configuration: We have verified that our email is properly set up and authorized to send emails. DNS Records: Our DNS records (SPF, DKIM, and DMARC) are configured to comply with email authentication standards. Whitelisting Sender Address: We attempted to whitelist the sender address as per recommendations but have not seen any improvement. Questions: Are there additional DNS configurations or records required for the Apple private relay to forward emails properly? Is there a process to validate our sender address with Apple to ensure email forwarding works? Are there specific guidelines or restrictions for sending emails to privaterelay.appleid.com addresses that we should follow? Is there a way to verify if Apple’s private relay email service is functioning correctly for our domain? Relevant Information: We use Keycloak to implement the OIDC protocol and store the private relay email address during the "Sign in with Apple" process. Our verification emails are sent from our email address. We have referred to the Apple documentation and community posts but could not find a clear resolution. Any guidance or recommendations from the community would be greatly appreciated. Thank you in advance for your support!

I have tried everything to get the user field returned with Sign in flow and it never does, not for new users, not even if i create a new app! Working with Apple is so frustrating and you have to pay for it!! Referencing this page, I am using scope=name email. I have tried using + and %20 as the spacer and neither makes a difference. I have also tried setting response_type = code and code id_token (again with + and %20 as the spacer) which also doesn't make a difference. Always the id_token is returned and always the email, but never the user. https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/incorporating_sign_in_with_apple_into_other_platforms#3332115 AUTHORIZE REQUEST https://appleid.apple.com/auth/authorize? { "response_type": "code", "client_id": "com.example.service", "scope": "name email", "state": "77264297-813c-4738-83ef-f1b77daea04c", "redirect_uri": "https://example.com/auth/apple/callback", "code_challenge_method": "S256", "code_challenge": "2SJCneEpjKcN.....xIIHnpqcvjK_Y0s", "access_type": "offline", "nonce": "1734523662", "response_mode": "form_post" } TOKEN REQUEST https://appleid.apple.com/auth/token? { "grant_type": "authorization_code", "code": "c870aaec987a14.....dqakaGP4Yn1nH3dnPgww", "client_id": "com.hikesync.service", "client_secret": "eyJhbGciOiJFUzI....3izij6dojYfdV6JMdbQPx3sOA", "redirect_uri": "https://hikesync.com/auth/apple/callback", "code_verifier": "38hHUC....mYuE0zfYVNTycg" } RESPONSE { "access_token": "a2b70e12d38b446....4hA7-RLNj0ifU5Q", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "rb4ed9be2b4024......w5RWjVFUQ", "id_token": "eyJraWQiOiJyQlJmV.......0Df0ihEJiA" } JWT { "iss": "https://appleid.apple.com", "aud": "SERVICE_ID", "exp": 1734606699, "iat": 1734520299, "sub": "000000.f7f7c0ac.....db9fad7e19.1111", "nonce": "NONCE", "at_hash": "NAfjmciTi2NtmPYIMAgjig", "email": "abc123@privaterelay.appleid.com", "email_verified": true, "is_private_email": true, "auth_time": 1734520297, "nonce_supported": true }

We are developing a captive portal for a community Wi-Fi service that will be deployed to thousands of locations around the world. The service is a paid service that sells Wi-Fi connectivity by data volume rather than time. We want to enable our customers to Sign in with Apple without giving them full internet access until they have made a purchase. This requires us to whitelist domains and URLs to make this work. Where can I find a complete list of domains that are required for Sign in with Apple to function correctly? It’s not possible for us to whitelist *.apple.com because that results in significant (free) background network traffic during the sign in process. So far we have whitelisted: account.apple.com appleid.apple.com appleid.apple-cdn.com idmsa.apple.com gsa.apple.com mzstatic.com Our customers are still having issues with Sign in with Apple while interacting with our captive portal in the iOS pseudo browser. How can we debug this because we cannot use the Safari developer tools with the pseudo browser. Are there any logs when doing this on a Mac that we can check in the Console? If we kick the user out to Safari then they are able to complete the Sign in with Apple process, but that is not the user experience we want.

Hello, We recently transferred our iOS app from an individual developer account to a corporate account. By following this guide (link), we successfully obtained the transfer identifiers for all our current users and have stored the data fetched from Apple. Now that the transfer has been completed for about 10 hours, we're attempting to remap the old identifiers to the new ones using this guide (link). Unfortunately, all our requests are returning an 'invalid_request' error. I've noticed others have faced the same problem, but I haven't found a solution yet. Can anyone help me resolve this issue?

https://developer.apple.com/documentation/sign_in_with_apple/revoke_tokens/ As shown in the documentation, when I tested via curl, I received a response with status 200, but when I logged in to account.apple.com with the linked account, it shows that it is still connected. I would like to know if there is any additional way to verify that the revoke api is working properly.

Hello Developers, I have ran into a problem while sending mail to apple private relay email. We have built a mobile application where user can sign up through apple and they can sign up using hide-my-email feature. Which provides private relay address for us. Now we want to communicate with them using private relay mail address. The technology we are using to send emails are amazon SES, have done SPF, DMIK, DMARC and added domains in apple identity services for mail communication, passed an SPF check as well. But still mail is not getting delivered what am i doing wrong or apple doesn't support third party apps for sending emails to private relay? Is there any other way to achieve this please let me know Using the same body as attached in image is working fine for rest emails.

Hello everyone, We recently transferred an iOS app but didn’t generate the transfer identifier before initiating the transfer. Is it still possible to generate the transfer identifier after the transfer has been completed? If not, are there any alternative solutions or steps we can take to resolve this issue? Thank you for any guidance!