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.

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?

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?

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.

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);

We use Sign in with Apple. Emails to @privaterelay.appleid.com bounce with "550 5.1.1 ...@send-subdomain: unauthorized sender" for 4+ days. Setup: Sending via Resend (Amazon SES, eu-west-1) From: siparis @ truefriends.com.tr, envelope: send.truefriends.com.tr All four Email Sources show green SPF in Certificates, IDs & Profiles: truefriends.com.tr (Domain) send.truefriends.com.tr (Domain) siparis @ truefriends.com.tr (Email) *@send.truefriends.com.tr (Email wildcard) — added today, no effect Test mail to non-Apple inbox: spf=pass, dkim=pass (d=truefriends.com.tr matches From), dmarc=pass. So full authentication is verified. Filed Feedback Assistant + Developer Support case 102902232938 — Tier 1 deflected to Feedback. Waiting for engineering response. Has anyone resolved a case where portal shows green ✓ but Relay still rejects as unauthorized? Internal sync issue?

Hi, The WWDC session noted App Attest is supported on macOS 27, but only for certain extension types (Action and SSO were the examples shown IIRC). Is there a definitive list of which extension types support DCAppAttestService on macOS 27 — and is the credential-provider extension (ASCredentialProviderExtension) among them? If credential-provider extensions are not supported, in an app that ships a credential-provider extension, can I add a separate (e.g. SSO or Action) extension — or use the containing app — to perform App Attest and generate/attest a key, then use that key from the credential-provider extension (e.g. via a shared keychain access group)? Or is the attested key inherently bound to the attesting process and not shareable? Thanks!

We have an application with multiple extension targets. We generate device check token using DCDevice.current.generateToken API. However while trying to validate the device using devicecheck.apple.com/v1/validate_device_token from our servers, we get success for our extension targets but failure for our app target. The transaction IDs are below For App target's device check token: 26050657-fa98-4d2e-8e28-eb0e4005cf15 For extension target's device check token: cfab83e0-8aa7-43e7-8343-f8baaec6ee651001 We assume this is because our main target has a different APPID prefix compared to our extension targets. Device validation API should not fail because the code signing is done from the same developer ID. Can you check on this? Or Can we use the device verify token from our extension targets for validating the app since extension targets are a bundled with app target by design?

Are there any plans to increase the DC token validity or enable using attestations to set the device check bit states? The current implementation makes it challenging to set bit states once we identify a device as belong to a bad actor after the fact. We need to actor to re-engage with the platform to be able to collect a DC token which mostly doesnt happen since they use burner accounts and move on.

Hi App Attest team, I was nodding along happily in the wwdc session, because it was seeming like an air tight solution to prevent API abuse while allowing "guest" access (e.g. not enforcing that users log in). Then I hit this line, "a compromised device can still pass attestations". How is that possible? Earlier in the session, the presenter said "[AppAttest] gives you the assurance that your app is running on a secure apple device". I'm trying to square these statements and understand the motivation of the 'fraud metric'. Thank you! Lou Ps. I'm so happy that AppAttest is available on Mac now. :D

The wwdc session mentioned that attestation keys survive app updates but not reinstalls. So it seems like if I try to create an assertion after reinstall from the key I pull from keychain, and include that assertion in my API payload to my backend, my backend will reject the assertion. Is there any mechanism for us to ask the client framework "is this key still valid"? Thanks again, Lou

My understanding from the App Attest wwdc session is that we store attestation keys in keychain on a per-user basis. For apps that don't require user login, I'm thinking of using StoreKit's AppTransactionID [1] as the identifier to discriminate keys. Do you have opinions on whether this is a valid pattern? [1] https://developer.apple.com/documentation/storekit/apptransaction/apptransactionid

Apple has provided a number of Swift Packages for backend development, including some new tools for wallet passes! Is there anything like this for attestation and device check capabilities for a swift-on-server product to consume? If not, consider this a placeholder for a future feedback request.

Hi! I have not seen this year's video yet, so please forgive me if this is answered. I notice a couple of folks here saying that AppAttest is (at least partially) supported on macOS 27. Is this correct? My specific use case is a "designed for iPad" app running on macOS. We use App Attest to make high-value requests to our headend services and would really like this to work on macOS as well.

We are deploying Platform SSO using the Secure Enclave authentication method. However, users are still being prompted for their username and password during registration. This undermines our goal of going passwordless and is causing deployment friction with customers. Once the Secure Enclave method is deployed and initialized, is there a way to suppress or skip this password dialog so users only authenticate via hardware/biometrics?

Since device check APIs (attestation) are not available for extensions like share extension and widget extension (at least in 26 and according to documentation still in 27) - is there any best practice how to still protect endpoints which are also called from these extensions? And subquestion: is there a technical limitation in iOS design that made it impossible to also support extensions.

We would like to implement Platform SSO with the new web authentication. Where is the protocol documented? I have the documentation from prior versions of PSSO but would like to see the updated documentation.

In the WWDC 2021 session Mitigate fraud with App Attest and DeviceCheck it is said that: App Attest is supported on devices that have a Secure Enclave, but there are cases, such as app extensions, where isSupported will still return false. The documentation shows that the following Macs have a Secure Enclave: MacBook Pro computers with Touch Bar (2016 and 2017) that contain the Apple T1 Chip Intel-based Mac computers that contain the Apple T2 Security Chip Mac computers with Apple silicon I'm using a 2018 15" MacBook Pro containing a T2 Security Chip for testing, however, DCAppAttestService.shared.isSupported always returns false in native macOS or Catalyst apps. DCDevice.current.isSupported also returns false. The documentation for DCAppAttestService shows availability on "macOS 11.0+" and "Mac Catalyst 14.0+". It appears to have been added in the macOS 11.3 SDK included in Xcode 12.5. DCDevice shows availability on "macOS 10.15+" and "Mac Catalyst 13.0+". Although both APIs are available on the listed OSes, I only ever see isSupported == false. Are App Attest or DeviceCheck functional on any Macs? If so: Are there more specific Macs that support the feature (e.g., Apple Silicon Macs only)? Are there any additional steps that need to be taken to use them (e.g., changes to entitlements, provisioning profiles or distribution through the Mac App Store)? In native macOS apps, it doesn't actually appear to be possible to add the App Attest capability in Xcode under "Signing & Capabilities". If not, I think it would be good to update the documentation with this limitation since I'd expect them to work based on the availability being "macOS 10.15+" or "macOS 11.0+" for DeviceCheck and App Attest, respectively. I imagine most others would make the same assumptions.

Hi, it's very urgency! https://developer.apple.com/forums/thread/818346 After long time preparation, We finally execute this transfer operation today. Works fine at preliminary stage, lots of users had been transferred successfully. However, about 25% users transferred failed at the end, 'invalid_request' response from https://appleid.apple.com/auth/usermigrationinfo. No matter how many times we retry, it does work. Please help! 700,000 users are waiting us!

Hello Everyone I'm encountering a problem with the Apple Mail Private. I created a website with the possibility to log in with apple account and apple gives the possibility to privatize the mail address with xxxxx@privaterelay. appleid.com but also blocked the mail come from my server. In the log I get the error: relay=smtp3.privaterelay. appleid.com[17.56.9.14]:25, delay=2.4, delays=0.11/0/1.8/0.48, dsn=5.1.1, status=bounced (host smtp3.privaterelay. appleid.com[17.56.9.14] said: 550 5.1.1 mymail@mail. com: unauthorized sender (in reply to RCPT TO command)) How can I fix it ?