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.

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?

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.

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.

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!

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.

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 received Apple’s recent notice about the new requirement to provide a server-to-server notification endpoint when registering or updating a Services ID that uses Sign in with Apple. (Official notice: https://developer.apple.com/news/?id=j9zukcr6 ) We already use Sign in with Apple on our website and app, but only as a login method for pre-registered users, not as a way to create new accounts. That means users already exist in our system, and Apple login is used only for authentication convenience (similar to linking a social account). I have some questions about how to properly implement the required server-to-server notifications in this case: 1. email-enabled / email-disabled: We don’t use or store the email address provided by Apple. Are we still required to handle these events, or can we safely ignore them if the email is not used in our system? 2. consent-revoked: We don’t store Apple access or refresh tokens, we use them only during login and discard them immediately. In this case, do we still need to handle token revocation, or can we simply unlink the Apple login from the user account when receiving this notification? 3. account-delete: If a user deletes their Apple account, we can unlink the Apple login and remove related Apple data, but we cannot delete the user’s primary account in our system (since the account exists independently). Is this acceptable under Apple’s requirements as well? We want to make sure our implementation aligns with Apple’s policy and privacy requirements, while maintaining consistency with our existing account management system. If anyone from Apple or other developers who implemented similar logic could provide guidance or share examples, it would be greatly appreciated. Thank you!

Hello, I currently have an app that includes the "Sign in with Apple" feature, and I need to transfer this app to another app team. I have reviewed all official documentation but have not found the answer I need. My situation has some specificities, and I hope to receive assistance. The .p8 key created by the original developer team has been lost, and the app’s backend does not use a .p8 key for verification—instead, it verifies by obtaining Apple’s public key. However, according to the official documentation I reviewed, obtaining a transfer identifier during the app transfer process requires a client_secret generated from the original team’s .p8 key. This has left us facing a challenge, and we have two potential approaches to address this issue: Q1: During the transfer, is it possible to skip obtaining the transfer identifier and proceed directly with the app transfer, without performing any backend operations? Is this approach feasible? Q2: If the above approach is not feasible, should we create a new .p8 key in the original team’s account and use this new key for the transfer? If a new key is generated, do we need to re-release a new version of the app before initiating the transfer? If neither of the above approaches is feasible, are there better solutions to resolve our issue? I hope to receive a response. Thank you. TN3159: Migrating Sign in with Apple users for an app transfer | Apple Developer Documentation/ https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team

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, I'm encountering a persistent 503 Server Temporarily Not Available error when trying to implement "Sign in with Apple" for my web application. I've already performed a full review of my configuration and I'm confident it's set up correctly, which makes this server-side error particularly confusing. Problem Description: Our web application uses Firebase Authentication to handle the "Sign in with Apple" flow. When a user clicks the sign-in button, they are correctly redirected to the appleid.apple.com authorization page. However, instead of seeing the login prompt, the page immediately displays a 503 Server Temporarily Not Available error. This is the redirect URL being generated (with the state parameter truncated for security): https://appleid.apple.com/auth/authorize?response_type=code&client_id=XXXXXX&redirect_uri=https%3A%2F%2FXXXXXX.firebaseapp.com%2F__%2Fauth%2Fhandler&state=AMbdmDk...&scope=email%20name&response_mode=form_post Troubleshooting Steps Performed: Initially, I was receiving an invalid_client error, which prompted me to meticulously verify every part of my setup. I have confirmed the following: App ID Configuration: The "Sign in with Apple" capability is enabled for our primary App ID. Services ID Configuration: We have a Services ID configured specifically for this. The "Sign in with Apple" feature is enabled on this Services ID. The domain is registered and verified under "Domains and Subdomains". Firebase Settings Match Apple Settings: The Services ID from Apple is used as the Client ID in our Firebase configuration. The Team ID is correct. We have generated a private key, and both the Key ID and the .p8 file have been correctly uploaded to Firebase. The key is not revoked in the Apple Developer portal. Since the redirect to Apple is happening with the correct client_id and redirect_uri, and the error is a 5xx server error (not a 4xx client error like invalid_client), I believe our configuration is correct and the issue might be on Apple's end. This has been happening consistently for some time. My Questions: What could be causing a persistent 503 Server Temporarily Not Available error on the /auth/authorize endpoint when all client-side configurations appear to be correct? What is the formal process for opening a technical support ticket (TSI) directly with Apple Developer Support for an issue like this? Thank you for any insights or help you can provide.

Migrating APP and users, obtaining the user's transfer_sub, an exception occurred: {"error":"invalid_request"} `POST /auth/usermigrationinfo HTTP/1.1 Host: appleid.apple.com Content-Type: application/x-www-form-urlencoded Authorization: Bearer {access_token} sub={sub}&target={recipient_team_id}&client_id={client_id}&client_secret={client_secret} The specific request is as follows: 15:56:20.858 AppleService - --> POST https://appleid.apple.com/auth/usermigrationinfo 15:56:20.858 AppleService - Content-Type: application/x-www-form-urlencoded 15:56:20.858 AppleService - Content-Length: 395 15:56:20.858 AppleService - Authorization: Bearer a56a8828048af48c0871e73b55d8910aa.0.rzvs.96uUcy1KBqo34Kj8qrPb4w 15:56:20.858 AppleService - 15:56:20.858 AppleService - sub=001315.1535dbadc15b472987acdf634719a06a.0600&target=WLN67KBBV8&client_id=com.hawatalk.live&client_secret=eyJraWQiOiIzODg5U1ZXNDM5IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJRMzlUU1BHMjk3IiwiaWF0IjoxNzU1MDcxNzc5LCJleHAiOjE3NTUwNzUzNzksImF1ZCI6Imh0dHBzOi8vYXBwbGVpZC5hcHBsZS5jb20iLCJzdWIiOiJjb20uaGF3YXRhbGsubGl2ZSJ9.8i9RYIcepuIiEqOMu1OOAlmmjnB84AJueel21gNapiNa9pr3498Zkj8J5MUIzvvnvsvUJkKQjp_VvnsG_IIrTA 15:56:20.859 AppleService - --> END POST (395-byte body) 15:56:21.675 AppleService - <-- 400 Bad Request https://appleid.apple.com/auth/usermigrationinfo(816ms) 15:56:21.675 AppleService - Server: Apple 15:56:21.675 AppleService - Date: Wed, 13 Aug 2025 07:56:22 GMT 15:56:21.675 AppleService - Content-Type: application/json;charset=UTF-8 15:56:21.675 AppleService - Content-Length: 27 15:56:21.675 AppleService - Connection: keep-alive 15:56:21.675 AppleService - Pragma: no-cache 15:56:21.675 AppleService - Cache-Control: no-store 15:56:21.676 AppleService - 15:56:21.676 AppleService - {"error":"invalid_request"} 15:56:21.676 AppleService - <-- END HTTP (27-byte body) ` Current Team ID: Q39TSPG297 Recipient Team ID: WLN67KBBV8 CLIENT_ID: com.hawatalk.live

I'm implementing Apple Sign-In in my Next.js application with a NestJS backend. After the user authenticates with Apple, instead of redirecting to my configured callback URL, the browser makes a POST request to a mysterious endpoint /appleauth/auth/federate that doesn't exist in my codebase, resulting in a 404 error. Tech Stack Frontend: Next.js 16.0.10, React 19.2.0 Backend: NestJS with Passport (using @arendajaelu/nestjs-passport-apple) Frontend URL: https://myapp.example.com Backend URL: https://api.example.com Apple Developer Configuration Service ID: (configured correctly in Apple Developer Console) Return URL (only one configured): https://api.example.com/api/v1/auth/apple/callback Domains verified in Apple Developer Console: myapp.example.com api.example.com example.com Backend Configuration NestJS Controller (auth.controller.ts): typescript @Public() @Get('apple') @UseGuards(AuthGuard('apple')) async appleAuth() { // Initiates Apple OAuth flow } @Public() @Post('apple/callback') // Changed from @Get to @Post for form_post @UseGuards(AuthGuard('apple')) async appleAuthCallback(@Req() req: any, @Res() res: any) { const result = await this.authService.socialLogin(req.user, ipAddress, userAgent); // Returns HTML with tokens that uses postMessage to send to opener window } Environment Variables: typescript APPLE_CLIENT_ID=<service_id> APPLE_TEAM_ID=<team_id> APPLE_KEY_ID=<key_id> APPLE_PRIVATE_KEY_PATH=./certs/AuthKey_XXX.p8 APPLE_CALLBACK_URL=https://api.example.com/api/v1/auth/apple/callback FRONTEND_URL=https://myapp.example.com The passport-apple strategy uses response_mode: 'form_post', so Apple POSTs the authorization response to the callback URL. Frontend Implementation Next.js API Route (/src/app/api/auth/apple/route.js): javascript export async function GET(request) { const backendUrl = new URL(`${API_URL}/auth/apple`); const response = await fetch(backendUrl.toString(), { method: "GET", headers: { "Content-Type": "application/json", }, }); const responseText = await response.text(); return new NextResponse(responseText, { status: response.status, headers: { "Content-Type": contentType || "text/html" }, }); } Frontend Auth Handler: javascript export const handleAppleLogin = (router, setApiError) => { const frontendUrl = window?.location?.origin; // Opens popup to /api/auth/apple window.open( `${frontendUrl}/api/auth/apple`, "appleLogin", "width=500,height=600" ); }; The Problem Expected Flow: User clicks "Login with Apple" Frontend opens popup → https://myapp.example.com/api/auth/apple Frontend proxies to → https://api.example.com/api/v1/auth/apple Backend redirects to Apple's authentication page User authenticates with Apple ID Apple POSTs back to → https://api.example.com/api/v1/auth/apple/callback Backend processes and returns success HTML Actual Behavior: After step 5 (user authentication with Apple), instead of Apple redirecting to my callback URL, the browser makes this unexpected request: POST https://myapp.example.com/appleauth/auth/federate?isRememberMeEnabled=false Status: 404 Not Found Request Payload: json { "accountName": "user@example.com", "rememberMe": false } Network Tab Analysis From Chrome DevTools, the call stack shows: send @ app.js:234 ajax @ app.js:234 (anonymous) @ app.js:10 Ee.isFederated @ app.js:666 _callAuthFederate @ app.js:666 The Ee.isFederated and _callAuthFederate functions appear to be minified library code, but I cannot identify which library. What I've Verified ✅ The /appleauth/auth/federate endpoint does not exist anywhere in my codebase: bash grep -r "appleauth" src/ # No results grep -r "federate" src/ # No results ✅ Apple Developer Console shows only ONE Return URL configured (verified multiple times) ✅ Changed callback route from @Get to @Post to handle form_post response mode ✅ Rebuilt frontend completely multiple times: bash rm -rf .next npm run build ✅ Tested in: Incognito/Private browsing mode Different browsers (Chrome, Firefox, Safari) Different devices After clearing all cache and cookies ✅ No service workers registered in the application ✅ No external <script> tags or CDN libraries loaded ✅ package.json contains no AWS Amplify, Auth0, Cognito, or similar federated auth libraries ✅ Checked layout.js and all root-level files - no external scripts Additional Context Google Sign-In works perfectly fine using the same approach The mysterious endpoint uses a different path structure (/appleauth/ vs /api/auth/) The call appears to originate from client-side JavaScript (based on the call stack) The app.js file with the mysterious functions is the built Next.js bundle Questions Where could this /appleauth/auth/federate endpoint be coming from? Why is the browser making this POST request instead of following Apple's redirect to my configured callback URL? Could this be related to the response_mode: 'form_post' in the Apple Passport strategy? Is there something in the Apple Developer Primary App ID configuration that could trigger this behavior? Could this be a Next.js build artifact or some hidden dependency? The mysterious call stack references (Ee.isFederated, _callAuthFederate) suggest some library is intercepting the Apple authentication flow, but I cannot identify what library or where it's being loaded from. The minified function names suggest federated authentication, but I have no such libraries in my dependencies. Has anyone encountered similar issues with Apple Sign-In where an unexpected endpoint is being called?

Hi, We are operating a service that uses Sign in with Apple for user registration and login. As part of our security incident response and periodic security improvements, we are planning to rotate the private key used to generate the client secret (JWT) for Sign in with Apple. I have read the Human Interface Guidelines and the AuthenticationServices documentation, but I could not find a clear description of the behavior and user impact when rotating this private key. I would like to ask the following questions: Background: We issue a Sign in with Apple private key (with a Key ID) in our Apple Developer account. Our server uses this private key to generate the client secret (JWT). This is used for Sign in with Apple login on our web / mobile app. We are planning to invalidate the existing private key and switch to a newly issued one. Questions: Impact on existing logged-in sessions Will rotating the private key force already logged-in users (who previously signed in with Apple) to be logged out from our service? Can the user identifier (such as the "sub" claim) for existing Sign in with Apple users change due to key rotation? Recommended frequency and best practices Does Apple recommend rotating this private key only when it is compromised, or on a regular basis? If there are any official documents or examples that describe how to safely perform key rotation in production, we would appreciate a pointer. Impact on marketing / analytics We are using user IDs (linked via Sign in with Apple) for analytics and marketing attribution. Is there any expected impact on such use cases caused by rotating the private key? For example, is there any possibility that user identifiers change as a result of key rotation, or anything we should be careful about from a data linkage perspective? Our goal is to rotate the private key in a secure way without causing service downtime, mass logouts, or loss of account linkage. If there is already an official document that covers this, please let me know the URL. Thank you in advance.

Recently I am trying to implement apple oauth in expo web version, I created the service id and other related info, i have issue @PostMapping("/callback") public ResponseEntity handleAppleCallback(@RequestParam Map<String, String> body) { String code = body.get("code"); String idToken = body.get("id_token"); if (code == null) { return ResponseEntity.badRequest().build(); } // Redirect to your Expo Web app with the code in query String frontendUrl = "https://mobile-dot-dev-epicportal.uc.r.appspot.com/apple-callback?code=" + code; return ResponseEntity.status(HttpStatus.FOUND) .header("Location", frontendUrl) .build(); } when i pass the code recived from apple to this route i am getting invalid_grant i am not sure what is wrong here

Hi everyone, We just completed an App Store Connect app transfer between two developer teams and ran into what seems like an inconsistency with TN3159 (Migrating Sign in with Apple users for an app transfer). According to the technote, both the source and destination teams should be able to call /auth/usermigrationinfo for 60 days after the transfer, even if the migration wasn’t run beforehand. However, right after the transfer completed, the source team (Team A) started receiving: {"error":"invalid_client"} on all /auth/usermigrationinfo requests, even though /auth/token with scope=user.migration still works fine. What we verified before transfer: Team A’s Sign in with Apple key (ES256) was linked to the app and Services ID. OAuth flow for com.org.appname.web returned valid tokens, and the decoded ID token showed aud=com.org.appname.web with a valid private relay email, confirming the key was trusted. What happens after transfer: The key now shows “Enabled Services: —” and the App/Services IDs are no longer selectable in the Developer portal. /auth/usermigrationinfo immediately returns invalid_client for Team A, even within the same day of the transfer. This effectively makes Team A unable to generate transfer_sub values, blocking the migration flow TN3159 describes. Questions: Is Team A supposed to retain authorization to call /auth/usermigrationinfo for 60 days post-transfer? If yes, is there any known workaround to re-authorize the key or temporarily re-bind it to the transferred identifiers? If not, does this mean transfer_sub must be generated before transfer acceptance, contrary to how TN3159 reads? Would really appreciate any confirmation or guidance from Apple or anyone who’s gone through this recently. Thanks,

We are integrating Sign in with Apple for our web application and have been stuck on an invalid_client error during the token exchange step. The Problem The authorization step works fine — the user authenticates on Apple's page and a valid authorization code is returned to our callback URL. However, when we exchange that code at https://appleid.apple.com/auth/token, it returns: {"error": "invalid_client"} The Puzzling Part When we send a dummy/expired authorization code with the exact same client_id and client_secret, Apple returns: {"error": "invalid_grant", "error_description": "The code has expired or has been revoked."} This confirms that our client credentials (client_id + client_secret JWT) are valid and accepted by Apple. The invalid_client error only occurs when a real, freshly-issued authorization code is used. Configuration Service ID configured with Sign in with Apple enabled Primary App ID with Sign in with Apple capability enabled Domain verified, Return URL registered Key created with Sign in with Apple enabled, linked to the correct Primary App ID Client Secret JWT Generated per Apple's documentation: Header: alg: ES256, kid set to our Key ID Claims: iss: Team ID iat: current timestamp exp: iat + 6 months (within Apple's limit) aud: https://appleid.apple.com sub: Service ID (matches the client_id used in authorization) Signed with: the .p8 private key associated with the Key Token Exchange Request POST https://appleid.apple.com/auth/tokenContent-Type: application/x-www-form-urlencodedclient_id=client_secret=code=grant_type=authorization_coderedirect_uri= What We've Tried Standalone test endpoint — built a minimal endpoint (no framework) that does the token exchange via server-side curl. Same invalid_client. Multiple Service IDs — created and tried 3 different Service IDs. All produce the same error with real codes. Multiple Keys — tried 2 different keys. Same error. Verified redirect_uri matches exactly between the authorization request and token request. Verified client_id matches exactly between the authorization URL and token request. Used client_secret_post (credentials in body, not Basic auth header). Freshness — code is used immediately upon receipt (within seconds), well before the 5-minute expiry. Filed a Developer Support case — was directed to Forums. Summary Scenario code Result Dummy/expired code abc123 invalid_grant (credentials accepted) Real fresh code from Apple callback invalid_client This pattern suggests something goes wrong specifically when Apple validates the authorization code against the client — even though the client credentials themselves are accepted in isolation. Has anyone encountered this behavior? Is there a known configuration issue that could cause invalid_client only with valid authorization codes? Any guidance would be greatly appreciated.

I set up "Sign in with Apple" via REST API according to the documentation. I can log in on my website and everything looks fine for the user. But I receive an email, that my "Sign in with Apple" account has been rejected by my own website. It states, I will have to re-submit my name and email address the next time I log in to this website. I don't see any error messages, no log entries, no HTTP errors anywhere. I also can't find anything in the docs, the emails seem to not be mentioned there, searching for anything with "rejected" in the forum did not yield any helpful result, because they are always about App entries being rejected etc. Did someone experience something similar yet? What's the reason, I'm getting these emails? I get them every time I go through the "Sign in with Apple" flow on my website again.

Our application currently uses Sign in with Apple through Microsoft Entra ID (B2C) rather than a direct integration with Apple's Authentication Services framework. We understand the requirement that users should not be asked to provide information that is already supplied by Sign in with Apple. However, in our current implementation, Microsoft Entra ID (B2C) does not provide the user's name details to our application, and as a result we are unable to access this information after authentication. Could you please provide guidance on how to satisfy this requirement when Sign in with Apple is configured through Microsoft Entra ID (B2C)? Specifically, we would appreciate clarification on whether there is an Apple-approved approach for obtaining the user's name in this federated authentication scenario without requiring the user to re-enter information. Apple rejected my app with these reasons "Issue Description The 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: The 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 log in to an account. Next Steps Please revise the Sign in with Apple experience in the app to address the issues we identified above. Resources To learn more about App Store design requirements, see guideline 4. For an overview of design and formatting recommendations for Sign in with Apple, review the Human Interface Guidelines."

Hello Apple Developer Community, I'm experiencing an invalid_client error (HTTP 400) when attempting to authenticate with the Apple School Manager API using OAuth2 with JWT bearer assertion (RFC 7523). Despite verifying all configuration values and following Apple's documentation, I continue to receive this error. Error Details Error: invalid_client HTTP Status: 400 Bad Request Endpoint: https://appleid.apple.com/auth/oauth2/v2/token Response: {"error": "invalid_client"} My Configuration All values have been verified to match Apple School Manager exactly: Organization ID: 55155430 Key ID: 8136a1f6-c995-4010-b964-bc8278c107ef Client ID (Service ID): SCHOOLAPI.7c0c10a0-4d8a-4ef8-a2be-eda040b65c59 Private Key: Loads correctly, signs JWT properly (ES256) JWT Configuration I'm generating a JWT with the following structure: Header: { "alg": "ES256", "kid": "8136a1f6-c995-4010-b964-bc8278c107ef", "typ": "JWT" } Payload: { "iss": "55155430", "sub": "SCHOOLAPI.7c0c10a0-4d8a-4ef8-a2be-eda040b65c59", "aud": "https://appleid.apple.com", "iat": [timestamp], "exp": [timestamp + 30 days] } Token Request Method: POST Content-Type: application/x-www-form-urlencoded Parameters: grant_type: client_credentials client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer client_assertion: [JWT token] scope: https://api.apple.com/auth/schoolmanager What I've Verified ✅ All configuration values match Apple School Manager exactly ✅ Private key file exists and loads correctly ✅ JWT is generated with correct structure (ES256, proper claims) ✅ Key ID in JWT header matches the Key ID from Apple School Manager ✅ Request format matches OAuth2 RFC 7523 specification ✅ Content-Type header is application/x-www-form-urlencoded ✅ Tried both Client ID and Organization ID as sub claim (both fail with same error) ✅ DNS resolution and API connectivity are working ✅ API account appears active in Apple School Manager interface What I've Tried Using Client ID as sub: Tried using SCHOOLAPI.7c0c10a0-4d8a-4ef8-a2be-eda040b65c59 as the sub claim Using Organization ID as sub: Tried using 55155430 as the sub claim (fallback) With and without scope: Tried both including and excluding the scope parameter Different JWT expiration: Tried various expiration times (30 days, 180 days) Verified Service ID format: Confirmed the Client ID follows the SCHOOLAPI.xxxxx-xxxxx-xxxxx format Both attempts (Client ID and Organization ID as sub) return the same invalid_client error. Previous Support Interaction I've contacted Apple Developer Support (Case #102783504559). They confirmed: The technical implementation is correct The issue is an account access/permission problem My Apple Account email is not associated with any memberships The Account Holder must add me to the Enterprise team membership However, I'm posting here to see if anyone in the community has: Experienced similar issues and found a solution Additional technical insights about the invalid_client error Suggestions for what else to verify or try Questions Is there a specific format requirement for the sub claim? Should it be the Client ID (Service ID) or Organization ID? I've tried both. Are there any additional claims required in the JWT beyond iss, sub, aud, iat, exp? Could there be a backend issue with the API account even though it appears active in Apple School Manager? Has anyone successfully resolved an invalid_client error that wasn't related to account access? Is there a delay after creating an API account before it becomes fully active for authentication? Technical Details Language: Python (Flask) JWT Library: PyJWT with cryptography library Algorithm: ES256 (ECDSA P-256) OAuth2 Flow: Client Credentials Grant with JWT Bearer Assertion (RFC 7523) Error Log I've generated a detailed error log showing the exact request/response. The key points: HTTP 400 Bad Request Response: {"error":"invalid_client"} Same error occurs with both Client ID and Organization ID as sub Any Help Appreciated If anyone has encountered this issue or has insights into what might be causing it, I'd greatly appreciate your help. I'm happy to provide additional details or try any suggestions. Thank you! Case Number: 102783504559 API Account: Created in Apple School Manager Status: API account appears active, but authentication fails

Hi everyone, I'm experiencing a persistent issue with Sign in with Apple on my iOS app that I cannot resolve from my side. I've already opened a support case (ID: 20000115382721) and received a reply directing me back to the Developer Forum, so I'm posting here in hopes someone has encountered the same issue or can offer guidance. Error message: FirebaseAuthException: [firebase_auth/invalid-credential] Invalid OAuth response from apple.com Critical observation: The Apple authentication screen never appears. When the user taps "Continue with Apple", the error is returned immediately. This suggests the request is being rejected before reaching Apple's authentication servers — pointing to a backend configuration issue on Apple's side for my Team ID. My setup: Team ID: DHKU23JL7H Bundle ID: com.expensespy.app Framework: Flutter with sign_in_with_apple package v7.0.1 Backend: Firebase Authentication Other auth methods (Google Sign-In, Email/Password): working correctly Verified configuration (all done correctly): App ID (com.expensespy.app): Sign In with Apple capability is enabled Configured as a primary App ID Not grouped with any other App ID Service ID (com.expensespy.app.auth): Created and linked to the primary App ID Domain: expensespy-e11ab.firebaseapp.com Return URL: https://expensespy-e11ab.firebaseapp.com/__/auth/handler All other redundant Service IDs have been removed Sign In with Apple Key: Created with Key ID X8T9NLBT4Y Linked to the primary App ID .p8 file is available Firebase Apple provider: Tested with OAuth code flow fields populated (Services ID, Team ID, Key ID, Private Key) — same error Tested with OAuth code flow fields empty (recommended for iOS-only) — same error Client-side implementation: Proper nonce generation with SHA256 hashing OAuthProvider('apple.com').credential() with idToken and rawNonce Tested across 3 different builds (Build 12, 13, 14) Tested on multiple iOS devices (iOS 18+) What I've ruled out: Client-side code (tested 3 different implementations) Firebase configuration (tested both populated and empty) Multiple Service IDs (cleaned up to just one) App ID configuration (verified primary status) Context: During my Apple Developer Program enrollment, I experienced an error that was not fully resolved. I suspect this may have left my account in a state where Sign in with Apple is not fully activated on the Apple backend for my Team ID. Question: Has anyone encountered this where the Apple auth screen never appears at all? Is there a way to verify that Sign in with Apple is properly provisioned for a specific Team ID on Apple's backend? My App Store submission is blocked by this since Sign in with Apple is required when offering third-party authentication. Any guidance from Apple engineers or developers who solved a similar issue would be deeply appreciated. Thanks!