Hi everyone, I have followed all the Apple procedures, read the forums, and looked at various experiences of other users who had my problem, but I haven’t found a solution. On my site, I have added login with all the “big” providers, and Apple is the only one missing. I’ve tried everything, but when the user logs in and is authenticated, I get an error. In order, here’s what I receive: Received Apple code: cfbf091dd6... JWT generated correctly HTTP Error (400): {"error":"invalid_client"} I’ve read all sorts of things, including that you have to wait up to 48 hours for the Key to be enabled. Any ideas? I’ve read that this is a common problem, but I haven’t found a valid solution. Thanks in advance to anyone who can help me.

I no longer have an app on the store. I do have an apple books account on the same login but there's no need for me to have the appstore connect account or whatever you call it and keep getting notifications when I don't have an app, don't want an app, will never do another app.

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, we are having Sign in with Apple issues. For a large % of new users on our app which select this option, the first name and last name values are not being passed to us. This is the case in both scenarios - where the user shares their email address or hides it, and happens on iPhone when the user selects the default iCloud account. We're unclear why this is occurring.

Hello everyone! We are from Russia, and we no longer have an official Apple store. All phones are imported through parallel imports. Yesterday, my wife logged out of her Apple ID and logged in to someone else's account, and as a result, her phone was in lost and locked mode. We have a sales receipt confirming the purchase, but it is from a Russian store. Can you please tell me if there is a way to unlock the phone or if it is already a brick? Scammers are asking for money to unlock the phone. Thank you in advance for your reply!

I’m using Sign in with Apple in my iOS app. When a user chooses “Hide My Email”, I receive the @privaterelay.appleid.com relay address. For marketing reasons, I would prefer to have the user’s real email address instead of the relay email. I want to stay compliant with App Store Review and the Sign in with Apple design/UX requirements. My questions are: Is it allowed to force the user (as part of the registration process) to provide their real email address, even if they chose “Hide My Email” during Sign in with Apple? Are there any specific App Store Review guidelines that forbid: Blocking sign up or access to features if the user keeps the relay email, or Showing a strong prompt like “We can’t log you in unless you share your real email”? What is the recommended, compliant pattern for collecting a “real” email when using Sign in with Apple + Private Relay? I’d appreciate any official clarification or examples of what App Review considers acceptable vs. reject-worthy here.

Hello, I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client. I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com). Here is an example of the decoded payload I received: { "iss": "https://appleid.apple.com", "aud": "xxx", "exp": 1764402438, "iat": 1764316038, "sub": "xxxxxxxx", "c_hash": "3FAJNf4TILzUgo_YFe4E0Q", "email": "xxx@privaterelay.appleid.com", "email_verified": true, "auth_time": 1764316038, "nonce_supported": true // "is_private_email": true <-- This field is missing } My Questions: Is the is_private_email claim considered optional in the ID Token? Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email? Any insights or official references would be appreciated. Thanks.

Hello, I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client. I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com). Here is an example of the decoded payload I received: { "iss": "https://appleid.apple.com", "aud": "com.platform.elderberry.new.signinwithapple", "exp": 1764402438, "iat": 1764316038, "sub": "000851.86193ef81ad247feb673746c19424f28.0747", "c_hash": "3FAJNf4TILzUgo_YFe4E0Q", "email": "x8sqp2dgvv@privaterelay.appleid.com", "email_verified": true, "auth_time": 1764316038, "nonce_supported": true // "is_private_email": true <-- This field is missing } My Questions: Is the is_private_email claim considered optional in the ID Token? Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email? Any insights or official references would be appreciated. Thanks.

I want to add the "Sign In with Apple" feature to my iPadOS application. I've already done the following: Include com.apple.developer.applesignin in mobileprovision Include com.apple.developer.applesignin in entitlements However, I'm getting the following errors: `Authorization failed: Error Domain=AKAuthenticationError Code=-7026 "(null)" UserInfo={AKClientBundleID=xxxx} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={_LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler, _LSFile=LSDReadService.mm, NSDebugDescription=process may not map database} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1000 "(null)" ` What is this problem? How can I solve it? Hoping someone can help, thank you!

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.

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?

I received a notification stating that we need to register a server-to-server notification endpoint to handle the following three events: Changes in email forwarding preferences. Account deletions in your app. Permanent Apple Account deletions. However, even though we have registered the API endpoint under our Identifier configuration, it appears that we are not receiving any API calls when these events trigger. I honestly have no idea what’s going wrong. I’ve checked our WAF logs and there’s no trace of any incoming traffic at all. Is it possible that Apple hasn't started sending these notifications yet, or is there something I might be missing? I’m stuck and don’t know how to resolve this. I would really appreciate any help or insights you could share. Thank you.

I received a notification stating that we need to register a server-to-server notification endpoint to handle the following three events: Changes in email forwarding preferences. Account deletions in your app. Permanent Apple Account deletions. However, even though we have registered the API endpoint under our Identifier configuration, it appears that we are not receiving any API calls when these events trigger. I honestly have no idea what’s going wrong. I’ve checked our WAF logs and there’s no trace of any incoming traffic at all. Is it possible that Apple hasn't started sending these notifications yet, or is there something I might be missing? I’m stuck and don’t know how to resolve this. I would really appreciate any help or insights you could share. Thank you.

Hello, I have a question regarding the lifecycle of user consent and tokens in "Sign in with Apple." Specifically, I would like to understand the behavior of the auth/revoke API in relation to App Store Connect status changes. Impact of App Status Changes If an app is "Removed from Sale" or "Deleted" from App Store Connect, does Apple automatically revoke all associated user tokens and consent? Or is it still the developer's responsibility to programmatically revoke each user's token via the REST API to ensure the app is removed from the user’s "Apps Using Apple ID" list? API Availability after Removal Once an app is no longer available on the App Store (or its record is deleted in App Store Connect), is the auth/revoke REST API still accessible? I want to ensure that a developer can still perform necessary privacy clean-up tasks (revoking consent) even if the app is not currently distributed. Specific User Impacts of Non-Revocation If we do not call the revocation API, besides the app remaining in the "Sign in with Apple" list, what are the specific consequences for the user? Thank you for your guidance.

Hi I am experiencing a persistent 'invalid_client' error when attempting to exchange the authorization code for an access token using Sign in with Apple for my website (https://www.vitamarinaweb.com). Current Setup & Steps Taken: Identifier: I am using the Service ID com.vitamarinaweb.web1, which is correctly linked to the Primary App ID com.vitamarinaweb.web. Client Secret: I have generated a fresh Client Secret (JWT) using a valid Key (.p8) and confirmed the Team ID (29J763Q88J) and Key ID (RRW6536D27) are correct. Redirect URIs: My Return URL is set to https://www.vitamarinaweb.com/login.php and I have verified there are no trailing spaces or mismatches. Manual Test (CURL): When I perform a manual POST request via CURL using the generated Client Secret, I receive an 'invalid_grant' response (meaning the Client Secret and Client ID are accepted, and only the temporary code is rejected as expected). The Issue: Despite the CURL success, every request initiated through the web browser/PHP application returns {"error":"invalid_client"}. Verification Requested: Could you please verify if there is a synchronization delay or a specific block on Service ID com.vitamarinaweb.web1? Is there any internal mismatch between the Key ID RRW6536D27 and its association with the newly created Service ID? I have already cleared browser caches and tried multiple devices (different IP addresses) with the same result. Thank you for your assistance."

Trying to make a new developer account but says I cannot. Here are the variables. I have a personal icloud account, it was tied to a developer organization account for an app and company I shut down. I let that developer account expire. Both tied to my mobile number. I can access it but cannot do anything. Trying to setup a new organization developer account using that mobile phone number, but it will not let me create the account. (have a new app/company) Used a different phone number and still got the message that I could not create a new account at this time.

I have a user (myself, during development) who originally signed in with Apple successfully. I attempted to revoke access via Settings > Apple ID > Sign-In & Security > Sign in with Apple, but the app appears stuck in the list and cannot be fully removed. Now when attempting to sign in again, the identity token contains the correct sub but email is undefined. According to Apple's documentation, "Apple provides the user's email address in the identity token on all subsequent API responses." I've tried programmatically revoking via the /auth/revoke endpoint (received 200 OK), and I've implemented the server-to-server notification endpoint to handle consent-revoked events, but subsequent sign-in attempts still return no email. The same Apple ID works fine with other apps. Is there a way to fully reset the credential state for a specific app, or is this a known issue with partially-revoked authorizations?

I have a user (myself, during development) who originally signed in with Apple successfully. I attempted to revoke access via Settings > Apple ID > Sign-In & Security > Sign in with Apple, but the app appears stuck in the list and cannot be fully removed. Now when attempting to sign in again, the identity token contains the correct sub but email is undefined. According to Apple's documentation, "Apple provides the user's email address in the identity token on all subsequent API responses." I've tried programmatically revoking via the /auth/revoke endpoint (received 200 OK), and I've implemented the server-to-server notification endpoint to handle consent-revoked events, but subsequent sign-in attempts still return no email. The same Apple ID works fine with other apps. Is there a way to fully reset the credential state for a specific app, or is this a known issue with partially-revoked authorizations?

Hello, I am currently process of migrating an app from Team A to Team B and attempting to generate transfer identifiers using the migration endpoint: POST https://appleid.apple.com/auth/usermigrationinfo. Content-Type: application/x-www-form-urlencoded However, I am consistently receiving an { "error": "access_denied" } response. [Current Configuration] Team A (Source): Primary App ID: com.example.primary Grouped App IDs: com.example.service (Services ID for Web) com.example.app (App ID for iOS - The one being transferred) All identifiers are under the same App Group. Team B (Destination): New App ID and Key created. [Steps Taken] Created a Client Secret (JWT) using Team A's Key ID and Team ID. The sub (subject) in the JWT is set to the Primary App ID of Team A. Requesting with client_id (Primary App ID), client_secret (JWT), and user_token. [Questions] 1. App Group Impact: Does the fact that the App being transferred is a Grouped App ID (not the Primary) affect the usermigrationinfo request? Should I use the Primary App ID or the specific Grouped App ID as the client_id? 2. Ungrouping Safety: If I need to ungroup the App ID from the Primary App ID to resolve this: Will existing users still be able to sign in without issues? Is there any risk of changing the sub (user identifier) that the app receives from Apple? Will this cause any immediate service interruption for the live app? Any insights on why access_denied occurs in this Primary-Grouped configuration would be greatly appreciated.

I'm testing app transferring, before, I have migrate user from teamA to teamB, including subA->transferSub->subB process, now I'm transfer the app from teamB to teamC, after the transfer requested, I can't get transfer_id by /usermigrationinfo api, which response 400 invalid request. the question is I can still get transfer sub by the auth/token api(grant_type: authorization_code) with teamB parameters(teamIdB/clientIdB/appSecretB/redirectUrlB/subB)，but the value is same as first time transfer_id which get during teamA to teamB. when use parameters above with target(teamIdC) to request /usermigrationinfo, invalid request was responsed. im sure that all parameters is correct, dose it cause by teamB still in 60-days first transferring(sure already accepted)?