Prioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.

All subtopics
Posts under Privacy & Security topic

Post

Replies

Boosts

Views

Activity

App transfer- get transfer {"error":"invalid_request"}
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
1
0
232
4d
Sudden Increase of Hard Bounce with privaterelay emails
We have been sending emails through Sparkpost via Braze inc. to the Apple Private Relay users with "@privaterelay.appleid.com" starting from around June 20th or so. Upon August 9th 06:00 UTC, we have noticed a sudden increase of "Hard Bounce" for nearly 20,000 users using the Apple's private relay email address, rendering the email sending useless for these customers. We have been constantly been able to send them emails, including just before this timeframe (e.g. August 9th 03:00 UTC), so it was a very sudden purge of the user data that has been done without our consent. From a business perspective, this hurts a lot for the un-sendable users since we have no way of contacting them if not for the private address. We are desperate to know what has happened for these customers that has been "hard bounced". We are suspecting that it should be tied to the private email and the users primary email (or user data's) tie in the Apple server being gone, but not sure enough since there is no such documentation nor any way to acknowledge what has happened anywhere. We will provide any information possible for resolving. Thank you.
1
0
372
4d
Unable to Save Services ID Configuration — “PATCH Not Supported” Error
I’m trying to update the Domains and Redirects section for my Services ID configuration in Apple Developer (for Sign in with Apple). When I add new domains and click Save, nothing happens. In the browser console, I see a network request that fails with: PATCH not supported What I’ve tried so far: Logging out/in and refreshing the page Clearing browser cache and cookies Trying in Safari, Chrome, and incognito mode Verifying domain formatting (HTTPS, no trailing slash, domain is live) The issue persists in all browsers I’ve tested. Request: Is this a known issue with the Developer portal, or is there an alternative method to update my Services ID domains? Any guidance would be appreciated. Thanks,
2
1
222
4d
Apple SignIn configuration change from Group to Primary ID
I have two applications, and I recently decided to add the Apple Sign In feature. Initially, I configured it for one of the apps as the Primary ID for this feature. Everything worked well, and I decided to add it to the second app. I made a mistake and used the First app as Primary ID using the "Group with an existing primary App ID" flag. Now, when I sign in using the second app, I don't see it in the list of apps in iPhone Settings for Apple Sign In; I only see the primary app. And with that, I no longer see a prompt for sharing/hiding email, and I am unable to revoke credentials correctly. I decided to change the Second app's Sign-in config and set it as the Primary ID for the feature. I was hoping to get two apps independent for the SignIn. However, it doesn't seem to make a difference. The second app behaves the same way, as long as the first app used SignIn, the second one always thinks that the user has already used that feature and never shows the correct prompt. Is there something I missed after changing the Configuration?
1
0
213
4d
Not receiving Sign in with Apple Server-to-Server Notifications despite correct configuration
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.
1
0
298
4d
Not receiving Sign in with Apple Server-to-Server Notifications despite correct configuration
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.
1
0
209
4d
Apple Sign-In Fails with Mysterious 404 Error on Non-Existent /appleauth/auth/federate Endpoint
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?
1
0
632
4d
Questions about user impact and best practices for rotating the private key used for Sign in with Apple
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.
1
0
194
4d
SignIn with Apple: Primary App Id of Service ID
Hi, I'm trying to implement web-browser SignIn with Apple with my new app. I'm trying to "Associate your website to your app" like described in this doc: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web So I created a Service ID for this specific login. I want this login page to display my app icon and name when presented to users. My issue: When I associate my new app the the service, the link is somehow not working. The login page show the "service" login (with a generic apple logo and the Service ID's name) instead of the actual App name. I'v been able to link my new service to older apps succesfully !!! (the login page correctly shows the old apps icons and names) Why is my new app not associated with the service ? I am missing something here ? is there an additionnal step that I need to take in order to link the service to my newest app ? Thanks !
1
1
201
4d
Sign in with Apple First Name & Last Name Values
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.
1
0
157
4d
Apple Oauth in expo web
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
1
0
194
4d
No way => HTTP (400): {"error":"invalid_client"}
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.
1
0
149
4d
TN3159 – /auth/usermigrationinfo returns invalid_client for Team A immediately after app transfer (within 60-day window)
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,
1
0
518
4d
Inquiry Regarding Mandatory Sign in With Apple Requirements for Korean Developers
I understand from the recent Apple Developer News that Korean developers are now required to register a URL to receive notifications from the Apple server when creating or modifying a Sign in With Apple Service ID. However, it is not clear whether simply registering the URL is sufficient, or if it is also mandatory to implement the real-time processing of those notifications. I am inquiring whether the processing part is also a mandatory requirement.
1
0
218
4d
ManagedApp on macOS 27: can an ACME-provisioned identity be hardware-bound + attested
Hey guys, I'm building a managed macOS app (credential-provider extension) that needs an MDM-provisioned, hardware-bound, attested identity via the ManagedApp framework on macOS 27 which just released days ago, and I've hit a documentation contradiction. By reading through the docs, my understanding of the ManagedApp identity path is com.apple.configuration.app.managed → Identities → com.apple.asset.credential.acme. But the OS27 ACME schema says, for both HardwareBound and Attest: "On macOS, this is a required key. Set the value to false" (https://github.com/apple/device-management/blob/seed_OS_27_0/declarative/declarations/assets/credentials/acme.yaml#L66) — implying a software key. However, the macOS 27 release notes say ManagedApp deploys "hardware-bound identities" on macOS. So I am wondering that on macOS 27 + Apple silicon, can a ManagedApp-provisioned ACME identity actually be HardwareBound: true / Attest: true? If yes, is the acme.yaml "set to false on macOS" text just stale? If no, how is the documented "hardware-bound identities" capability delivered? And would that identity gonna be able to be used by the app / app extension? Thanks!
1
0
54
4d
Sign in with Apple Web: invalid_client on token exchange with real authorization code, but invalid_grant with dummy code
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.
1
0
443
4d
Cannot set nested subdomains in web auth configuration
For my api I have a domain scheme of env.service.example.com. I am trying to setup sign in with apple, however, when trying to set my return urls, the env subdomain is stripped, making the return url incorrect. For example, when I try to set https://env.service.example.com/ it is changed to https://service.example.com/ when submitted. Is there any way around this issue?
1
0
221
4d
SPF verification fails for long records (3+ DNS TXT strings) in Private Email Relay
Hi, we are experiencing a specific issue with the Private Email Relay service. Our domain e.glassesdirect.co.uk consistently fails SPF verification while our other domains pass. The Pattern: We've noticed that domains with SPF records fitting in 1-2 TXT strings pass, but this specific domain (~750 chars, 3 TXT strings) fails. Technical Details: Team ID: SM2J7LWD33 Domain: e.glassesdirect.co.uk SPF Record length: ~750 characters Third-party tools (MxToolbox) confirm the record is valid. We suspect Apple's verification parser might be failing to handle concatenated TXT strings or hitting a size limit. Could any Apple engineers confirm if there is a character limit or a bug in handling multi-part TXT records?
1
0
340
4d
Received email that my Sign in with Apple account was rejected
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.
2
0
459
4d
Apple Sign-In: "invalid-credential" error despite correct configuration - Firebase Auth iOS
Problem Summary I'm experiencing a persistent invalid-credential error with Apple Sign-In on iOS despite having verified every aspect of the configuration over the past 6 months. The error occurs at the Firebase Authentication level after successfully receiving credentials from Apple. Error Message: Firebase auth error: invalid-credential - Invalid OAuth response from apple.com. Environment Platform: iOS (Flutter app) Firebase Auth: v5.7.0 Sign in with Apple: v6.1.2 Xcode: Latest version with capability enabled iOS Target: 13.0+ Bundle ID: com.harmonics.orakl What Actually Happens ✅ Apple Sign-In popup appears ✅ User can authenticate with Apple ID ✅ Apple returns credentials with identityToken ❌ Firebase rejects with invalid-credential error The error occurs at Firebase level, not Apple level. What I've Tried Created a brand new Apple Key (previous key was 6 months old) Tested with both App ID and Service ID in Firebase Completely reinstalled CocoaPods dependencies Verified nonce handling is correct (hashed to Apple, raw to Firebase) Activated Firebase Hosting and attempted to deploy .well-known file Checked Cloud Logging (no detailed error messages found) Disabled and re-enabled Apple Sign-In provider in Firebase Verified Return URL matches exactly Waited and retried multiple times over 6 months Questions Is the .well-known/apple-developer-domain-association.txt file required? If yes, how should it be generated? Firebase Hosting doesn't auto-generate it. Could there be a server-side caching/blacklist issue with my domain or Service ID after multiple failed attempts? Should the Apple Key be linked to the Service ID instead of the App ID? The key shows as linked to Z3NNDZVWMZ.com.harmonics.orakl (the App ID). Is there any way to get more detailed error logs from Firebase about why it's rejecting the Apple OAuth response? Could using a custom domain instead of .firebaseapp.com resolve the issue? Additional Context Google Sign-In works perfectly on the same app The configuration has been reviewed by multiple developers Error persists across different devices and iOS versions No errors in Xcode console except the Firebase rejection Any help would be greatly appreciated. I've exhausted all standard troubleshooting steps and documentation. Project Details: Bundle ID: com.harmonics.orakl Firebase Project: harmonics-app Team ID: Z3N....... code : // 1. Generate raw nonce final String rawNonce = _generateRandomNonce(); // 2. Hash with SHA-256 final String hashedNonce = _sha256Hash(rawNonce); // 3. Send HASHED nonce to Apple ✅ final appleCredential = await SignInWithApple.getAppleIDCredential( scopes: [AppleIDAuthorizationScopes.email, AppleIDAuthorizationScopes.fullName], nonce: hashedNonce, // Correct: hashed nonce to Apple ); // 4. Create Firebase credential with RAW nonce ✅ final oauthCredential = OAuthProvider("apple.com").credential( idToken: appleCredential.identityToken!, rawNonce: rawNonce, // Correct: raw nonce to Firebase ); // 5. Sign in with Firebase - ERROR OCCURS HERE ❌ await FirebaseAuth.instance.signInWithCredential(oauthCredential);
3
0
618
4d
App transfer- get transfer {"error":"invalid_request"}
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
Replies
1
Boosts
0
Views
232
Activity
4d
Sudden Increase of Hard Bounce with privaterelay emails
We have been sending emails through Sparkpost via Braze inc. to the Apple Private Relay users with "@privaterelay.appleid.com" starting from around June 20th or so. Upon August 9th 06:00 UTC, we have noticed a sudden increase of "Hard Bounce" for nearly 20,000 users using the Apple's private relay email address, rendering the email sending useless for these customers. We have been constantly been able to send them emails, including just before this timeframe (e.g. August 9th 03:00 UTC), so it was a very sudden purge of the user data that has been done without our consent. From a business perspective, this hurts a lot for the un-sendable users since we have no way of contacting them if not for the private address. We are desperate to know what has happened for these customers that has been "hard bounced". We are suspecting that it should be tied to the private email and the users primary email (or user data's) tie in the Apple server being gone, but not sure enough since there is no such documentation nor any way to acknowledge what has happened anywhere. We will provide any information possible for resolving. Thank you.
Replies
1
Boosts
0
Views
372
Activity
4d
Unable to Save Services ID Configuration — “PATCH Not Supported” Error
I’m trying to update the Domains and Redirects section for my Services ID configuration in Apple Developer (for Sign in with Apple). When I add new domains and click Save, nothing happens. In the browser console, I see a network request that fails with: PATCH not supported What I’ve tried so far: Logging out/in and refreshing the page Clearing browser cache and cookies Trying in Safari, Chrome, and incognito mode Verifying domain formatting (HTTPS, no trailing slash, domain is live) The issue persists in all browsers I’ve tested. Request: Is this a known issue with the Developer portal, or is there an alternative method to update my Services ID domains? Any guidance would be appreciated. Thanks,
Replies
2
Boosts
1
Views
222
Activity
4d
Apple SignIn configuration change from Group to Primary ID
I have two applications, and I recently decided to add the Apple Sign In feature. Initially, I configured it for one of the apps as the Primary ID for this feature. Everything worked well, and I decided to add it to the second app. I made a mistake and used the First app as Primary ID using the "Group with an existing primary App ID" flag. Now, when I sign in using the second app, I don't see it in the list of apps in iPhone Settings for Apple Sign In; I only see the primary app. And with that, I no longer see a prompt for sharing/hiding email, and I am unable to revoke credentials correctly. I decided to change the Second app's Sign-in config and set it as the Primary ID for the feature. I was hoping to get two apps independent for the SignIn. However, it doesn't seem to make a difference. The second app behaves the same way, as long as the first app used SignIn, the second one always thinks that the user has already used that feature and never shows the correct prompt. Is there something I missed after changing the Configuration?
Replies
1
Boosts
0
Views
213
Activity
4d
Not receiving Sign in with Apple Server-to-Server Notifications despite correct configuration
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.
Replies
1
Boosts
0
Views
298
Activity
4d
Not receiving Sign in with Apple Server-to-Server Notifications despite correct configuration
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.
Replies
1
Boosts
0
Views
209
Activity
4d
Apple Sign-In Fails with Mysterious 404 Error on Non-Existent /appleauth/auth/federate Endpoint
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?
Replies
1
Boosts
0
Views
632
Activity
4d
Questions about user impact and best practices for rotating the private key used for Sign in with Apple
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.
Replies
1
Boosts
0
Views
194
Activity
4d
SignIn with Apple: Primary App Id of Service ID
Hi, I'm trying to implement web-browser SignIn with Apple with my new app. I'm trying to "Associate your website to your app" like described in this doc: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web So I created a Service ID for this specific login. I want this login page to display my app icon and name when presented to users. My issue: When I associate my new app the the service, the link is somehow not working. The login page show the "service" login (with a generic apple logo and the Service ID's name) instead of the actual App name. I'v been able to link my new service to older apps succesfully !!! (the login page correctly shows the old apps icons and names) Why is my new app not associated with the service ? I am missing something here ? is there an additionnal step that I need to take in order to link the service to my newest app ? Thanks !
Replies
1
Boosts
1
Views
201
Activity
4d
Sign in with Apple First Name & Last Name Values
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.
Replies
1
Boosts
0
Views
157
Activity
4d
Apple Oauth in expo web
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
Replies
1
Boosts
0
Views
194
Activity
4d
No way => HTTP (400): {"error":"invalid_client"}
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.
Replies
1
Boosts
0
Views
149
Activity
4d
TN3159 – /auth/usermigrationinfo returns invalid_client for Team A immediately after app transfer (within 60-day window)
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,
Replies
1
Boosts
0
Views
518
Activity
4d
Inquiry Regarding Mandatory Sign in With Apple Requirements for Korean Developers
I understand from the recent Apple Developer News that Korean developers are now required to register a URL to receive notifications from the Apple server when creating or modifying a Sign in With Apple Service ID. However, it is not clear whether simply registering the URL is sufficient, or if it is also mandatory to implement the real-time processing of those notifications. I am inquiring whether the processing part is also a mandatory requirement.
Replies
1
Boosts
0
Views
218
Activity
4d
ManagedApp on macOS 27: can an ACME-provisioned identity be hardware-bound + attested
Hey guys, I'm building a managed macOS app (credential-provider extension) that needs an MDM-provisioned, hardware-bound, attested identity via the ManagedApp framework on macOS 27 which just released days ago, and I've hit a documentation contradiction. By reading through the docs, my understanding of the ManagedApp identity path is com.apple.configuration.app.managed → Identities → com.apple.asset.credential.acme. But the OS27 ACME schema says, for both HardwareBound and Attest: "On macOS, this is a required key. Set the value to false" (https://github.com/apple/device-management/blob/seed_OS_27_0/declarative/declarations/assets/credentials/acme.yaml#L66) — implying a software key. However, the macOS 27 release notes say ManagedApp deploys "hardware-bound identities" on macOS. So I am wondering that on macOS 27 + Apple silicon, can a ManagedApp-provisioned ACME identity actually be HardwareBound: true / Attest: true? If yes, is the acme.yaml "set to false on macOS" text just stale? If no, how is the documented "hardware-bound identities" capability delivered? And would that identity gonna be able to be used by the app / app extension? Thanks!
Replies
1
Boosts
0
Views
54
Activity
4d
Sign in with Apple Web: invalid_client on token exchange with real authorization code, but invalid_grant with dummy code
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.
Replies
1
Boosts
0
Views
443
Activity
4d
Cannot set nested subdomains in web auth configuration
For my api I have a domain scheme of env.service.example.com. I am trying to setup sign in with apple, however, when trying to set my return urls, the env subdomain is stripped, making the return url incorrect. For example, when I try to set https://env.service.example.com/ it is changed to https://service.example.com/ when submitted. Is there any way around this issue?
Replies
1
Boosts
0
Views
221
Activity
4d
SPF verification fails for long records (3+ DNS TXT strings) in Private Email Relay
Hi, we are experiencing a specific issue with the Private Email Relay service. Our domain e.glassesdirect.co.uk consistently fails SPF verification while our other domains pass. The Pattern: We've noticed that domains with SPF records fitting in 1-2 TXT strings pass, but this specific domain (~750 chars, 3 TXT strings) fails. Technical Details: Team ID: SM2J7LWD33 Domain: e.glassesdirect.co.uk SPF Record length: ~750 characters Third-party tools (MxToolbox) confirm the record is valid. We suspect Apple's verification parser might be failing to handle concatenated TXT strings or hitting a size limit. Could any Apple engineers confirm if there is a character limit or a bug in handling multi-part TXT records?
Replies
1
Boosts
0
Views
340
Activity
4d
Received email that my Sign in with Apple account was rejected
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.
Replies
2
Boosts
0
Views
459
Activity
4d
Apple Sign-In: "invalid-credential" error despite correct configuration - Firebase Auth iOS
Problem Summary I'm experiencing a persistent invalid-credential error with Apple Sign-In on iOS despite having verified every aspect of the configuration over the past 6 months. The error occurs at the Firebase Authentication level after successfully receiving credentials from Apple. Error Message: Firebase auth error: invalid-credential - Invalid OAuth response from apple.com. Environment Platform: iOS (Flutter app) Firebase Auth: v5.7.0 Sign in with Apple: v6.1.2 Xcode: Latest version with capability enabled iOS Target: 13.0+ Bundle ID: com.harmonics.orakl What Actually Happens ✅ Apple Sign-In popup appears ✅ User can authenticate with Apple ID ✅ Apple returns credentials with identityToken ❌ Firebase rejects with invalid-credential error The error occurs at Firebase level, not Apple level. What I've Tried Created a brand new Apple Key (previous key was 6 months old) Tested with both App ID and Service ID in Firebase Completely reinstalled CocoaPods dependencies Verified nonce handling is correct (hashed to Apple, raw to Firebase) Activated Firebase Hosting and attempted to deploy .well-known file Checked Cloud Logging (no detailed error messages found) Disabled and re-enabled Apple Sign-In provider in Firebase Verified Return URL matches exactly Waited and retried multiple times over 6 months Questions Is the .well-known/apple-developer-domain-association.txt file required? If yes, how should it be generated? Firebase Hosting doesn't auto-generate it. Could there be a server-side caching/blacklist issue with my domain or Service ID after multiple failed attempts? Should the Apple Key be linked to the Service ID instead of the App ID? The key shows as linked to Z3NNDZVWMZ.com.harmonics.orakl (the App ID). Is there any way to get more detailed error logs from Firebase about why it's rejecting the Apple OAuth response? Could using a custom domain instead of .firebaseapp.com resolve the issue? Additional Context Google Sign-In works perfectly on the same app The configuration has been reviewed by multiple developers Error persists across different devices and iOS versions No errors in Xcode console except the Firebase rejection Any help would be greatly appreciated. I've exhausted all standard troubleshooting steps and documentation. Project Details: Bundle ID: com.harmonics.orakl Firebase Project: harmonics-app Team ID: Z3N....... code : // 1. Generate raw nonce final String rawNonce = _generateRandomNonce(); // 2. Hash with SHA-256 final String hashedNonce = _sha256Hash(rawNonce); // 3. Send HASHED nonce to Apple ✅ final appleCredential = await SignInWithApple.getAppleIDCredential( scopes: [AppleIDAuthorizationScopes.email, AppleIDAuthorizationScopes.fullName], nonce: hashedNonce, // Correct: hashed nonce to Apple ); // 4. Create Firebase credential with RAW nonce ✅ final oauthCredential = OAuthProvider("apple.com").credential( idToken: appleCredential.identityToken!, rawNonce: rawNonce, // Correct: raw nonce to Firebase ); // 5. Sign in with Firebase - ERROR OCCURS HERE ❌ await FirebaseAuth.instance.signInWithCredential(oauthCredential);
Replies
3
Boosts
0
Views
618
Activity
4d