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.

We're integrating Sign in with Apple into our iOS app The Apple ID login UI appears correctly on real devices, but after tapping Continue, the system immediately stops and shows code 1001. This issue happens across multiple devices and Apple ID accounts, even with no prior login history. We’ve confirmed the following Sign in with Apple is enabled in both Developer Portal and Xcode Capabilities Automatic signing and provisioning are set correctly Device is signed into iCloud and system time is synced Performed clean build, app reinstall, and other standard debugging steps We suspect that the sign in handshake process may not be completing properly due to some kind of account or server-side restriction, and we’d appreciate any insights into this behavior.

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 was experiencing a weird sign in error when using apple sign in with my app and wanted to put it here for anyone else who might experience it in the future, and so apple can make this requirement more clear. I was using CloudKit and apple sign in. If you are not using both this probably does not apply to you. Every time I would go to sign in in the iOS simulator I would enter my password, hit "sign in", and everything just froze. The very odd reason for this is if you are using iCloudKit and apple sign in you need to go to specifically the "identifiers" in the "Certificates, Identifiers & Profiles" menu (https://developer.apple.com/account/resources/identifiers/list). And from there you specifically need an App ID Configuration with apple sign in enabled. From there you have to have the same exact bundle identifier in Xcode under project settings(not an upper tab just click your project in the left panel). And that should allow you to both pass validation and have your sign in work. Hope this helps!

Hi I'm developing an app that autofills Passkeys. The app allows the user to authenticate to their IdP to obtain an access token. Using the token the app fetches from <server>/attestation/options. The app will generate a Passkey credential using a home-grown module - the extension has no involvement, neither does ASAuthorizationSecurityKeyPublicKeyCredentialProvider. I can confirm the passkey does get created. Next the credential is posted to <server>/attestation/results with the response JSON being parsed and used to create a ASPasskeyCredentialIdentity - a sample of the response JSON is attached. Here is my save function: static func save(authenticator: AuthenticatorInfo) async throws { guard let credentialID = Data(base64URLEncoded: authenticator.attributes.credentialId) else { throw AuthenticatorError.invalidEncoding("Credential ID is not a valid Base64URL string.") } guard let userHandle = authenticator.userId.data(using: .utf8) else { throw AuthenticatorError.invalidEncoding("User handle is not a valid UTF-8 string.") } let identity = ASPasskeyCredentialIdentity( relyingPartyIdentifier: authenticator.attributes.rpId, userName: authenticator.userId, // This is what the user sees in the UI credentialID: credentialID, userHandle: userHandle, recordIdentifier: authenticator.id ) try await ASCredentialIdentityStore.shared.saveCredentialIdentities([identity]) } Although no error occurs, I don't get any identities returned when I call this method: let identities = await ASCredentialIdentityStore.shared.credentialIdentities( forService: nil, credentialIdentityTypes: [.passkey] ) Here is the Info.plist in the Extension: <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionAttributes</key> <dict> <key>ASCredentialProviderExtensionCapabilities</key> <dict> <key>ProvidesPasskeys</key> <true/> </dict> <key>ASCredentialProviderExtensionShowsConfigurationUI</key> <true/> </dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.authentication-services-credential-provider-ui</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).CredentialProviderViewController</string> </dict> </dict> </plist> The entitlements are valid and the app and extension both support the same group. I'm stumped as to why the identity is not getting saved. Any ideas and not getting retrieved. attestationResult.json

I regularly see folks confused by the difference in behaviour of app groups between macOS and iOS. There have been substantial changes in this space recently. While much of this is now covered in the official docs (r. 92322409), I’ve updated this post to go into all the gory details. If you have questions or comments, start a new thread with the details. Put it in the App & System Services > Core OS topic area and tag it with Code Signing and Entitlements. Oh, and if your question is about app group containers, also include Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App Groups: macOS vs iOS: Working Towards Harmony There are two styles of app group ID: iOS-style app group IDs start with group., for example, group.eskimo1.test. macOS-style app group IDs start with your Team ID, for example, SKMME9E2Y8.eskimo1.test. This difference has been the source of numerous weird problems over the years. Starting in Feb 2025, iOS-style app group IDs are fully supported on macOS for all product types [1]. If you’re writing new code that uses app groups, use an iOS-style app group ID. If you have existing code that uses a macOS-style app group ID, consider how you might transition to the iOS style. IMPORTANT The Feb 2025 changes aren’t tied to an OS release but rather to a Developer website update. For more on this, see Feb 2025 Changes, below. [1] If your product is a standalone executable, like a daemon or agent, wrap it in an app-like structure, as explained in Signing a daemon with a restricted entitlement. iOS-Style App Group IDs An iOS-style app group ID has the following features: It starts with the group. prefix, for example, group.eskimo1.test. You allocate it on the Developer website. This assigns the app group ID to your team. You then claim access to it by listing it in the App Groups entitlement (com.apple.security.application-groups) entitlement. That claim must be authorised by a provisioning profile [1]. The Developer website will only let you include your team’s app group IDs in your profile. For more background on provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. iOS-style app group IDs originated on iOS with iOS 3.0. They’ve always been supported on iOS’s child platforms (iPadOS, tvOS, visionOS, and watchOS). On the Mac: They’ve been supported by Mac Catalyst since that technology was introduced. Likewise for iOS Apps on Mac. Starting in Feb 2025, they’re supported for other Mac products. [1] Strictly speaking macOS does not require that, but if your claim is not authorised by a profile then you might run into other problems. See Entitlements-Validated Flag, below. macOS-Style App Group IDs A macOS-style app group ID has the following features: It should start with your Team ID [1], for example, SKMME9E2Y8.eskimo1.test. It can’t be explicitly allocated on the Developer website. Code that isn’t sandboxed doesn’t need to claim the app group ID in the App Groups entitlement. [2] To use an app group, claim the app group ID in the App Groups entitlement. The App Groups entitlement is not restricted on macOS, meaning that this claim doesn’t need to be authorised by a provisioning profile [3]. However, if you claim an app group ID that’s not authorised in some way, you might run into problems. More on that later in this post. If you submit an app to the Mac App Store, the submission process checks that your app group IDs make sense, that is, they either start with your Team ID (macOS style) or are assigned to your team (iOS style). [1] This is “should” because, historically, macOS has not actually required it. However, that’s now changing, with things like app group container protection. [2] This was true prior to macOS 15. It may still technically be true in macOS 15 and later, but the most important thing, access to the app group container, requires the entitlement because of app group container protection. [3] Technically it’s a validation-required entitlement, something that we’ll come back to in the Entitlements-Validated Flag section. Feb 2025 Changes On 21 Feb 2025 we rolled out a change to the Developer website that completes the support for iOS-style app group IDs on the Mac. Specifically, it’s now possible to create a Mac provisioning profile that authorises the use of an iOS-style app group ID. Note This change doesn’t affect Mac Catalyst or iOS Apps on Mac, which have always been able to use iOS-style app group IDs on the Mac. Prior to this change it was possible to use an iOS-style app group ID on the Mac but that might result in some weird behaviour. Later sections of this post describe some of those problems. Of course, that information is now only of historical interest because, if you’re using an iOS-style app group, you can and should authorise that use with a provisioning profile. We also started seeding Xcode 16.3, which has since been release. This is aware of the Developer website change, and its Signing & Capabilities editor actively encourages you to use iOS-style app groups IDs in all products. Note This Xcode behaviour is the only option for iOS and its child platforms. With Xcode 16.3, it’s now the default for macOS as well. If you have existing project, enable this behaviour using the Register App Groups build setting. Finally, we updated a number of app group documentation pages, including App Groups entitlement and Configuring app groups. Crossing the Streams In some circumstances you might need to have a single app that accesses both an iOS- and a macOS-style app group. For example: You have a macOS app. You want to migrate to an iOS-style app group ID, perhaps because you want to share an app group container with a Mac Catalyst app. But you also need to access existing content in a container identified by a macOS-style app group ID. Historically this caused problems (FB16664827) but, as of Jun 2025, this is fully supported (r. 148552377). When the Developer website generates a Mac provisioning profile for an App ID with the App Groups capability, it automatically adds TEAM_ID.* to the list of app group IDs authorised by that profile (where TEAM_ID is your Team ID). This allows the app to claim access to every iOS-style app group ID associated with the App ID and any macOS-style app group IDs for that team. This helps in two circumstances: It avoids any Mac App Store Connect submission problems, because App Store Connect can see that the app’s profile authorises its use of all the it app group IDs it claims access to. Outside of App Store — for example, when you directly distribute an app using Developer ID signing — you no longer have to rely on macOS granting implicit access to macOS-style app group IDs. Rather, such access is explicitly authorised by your profile. That ensures that your entitlements remain validated, as discussed in the Entitlements-Validated Flag, below. A Historical Interlude These different styles of app group IDs have historical roots: On iOS, third-party apps have always used provisioning profiles, and thus the App Groups entitlement is restricted just like any other entitlement. On macOS, support for app groups was introduced before macOS had general support for provisioning profiles [1], and thus the App Groups entitlement is unrestricted. The unrestricted nature of this entitlement poses two problems. The first is accidental collisions. How do you prevent folks from accidentally using an app group ID that’s in use by some other developer? On iOS this is easy: The Developer website assigns each app group ID to a specific team, which guarantees uniqueness. macOS achieved a similar result by using the Team ID as a prefix. The second problem is malicious reuse. How do you prevent a Mac app from accessing the app group containers of some other team? Again, this isn’t an issue on iOS because the App Groups entitlement is restricted. On macOS the solution was for the Mac App Store to prevent you from publishing an app that used an app group ID that’s used by another team. However, this only works for Mac App Store apps. Directly distributed apps were free to access app group containers of any other app. That was considered acceptable back when the Mac App Store was first introduced. That’s no longer the case, which is why macOS 15 introduced app group container protection. See App Group Container Protection, below. [1] I’m specifically talking about provisioning profiles for directly distributed apps, that is, apps using Developer ID signing. Entitlements-Validated Flag The fact that the App Groups entitlement is unrestricted on macOS is, when you think about it, a little odd. The purpose of entitlements is to gate access to functionality. If an entitlement isn’t restricted, it’s not much of a gate! For most unrestricted entitlements that’s not a problem. Specifically, for both the App Sandbox and Hardened Runtime entitlements, those are things you opt in to, so macOS is happy to accept the entitlement at face value. After all, if you want to cheat you can just not opt in [1]. However, this isn’t the case for the App Groups entitlement, which actually gates access to functionality. Dealing with this requires macOS to walk a fine line between security and compatibility. Part of that solution is the entitlements-validated flag. When a process runs an executable, macOS checks its entitlements. There are two categories: Restricted entitlements must be authorised by a provisioning profile. If your process runs an executable that claims a restricted entitlement that’s not authorised by a profile, the system traps. Unrestricted entitlements don’t have to be authorised by a provisioning profile; they can be used by any code at any time. However, the App Groups entitlement is a special type of unrestricted entitlement called a validation-required entitlement. If a process runs an executable that claims a validation-required entitlement and that claim is not authorised by a profile, the system allows the process to continue running but clears its entitlements-validated flag. Some subsystems gate functionality on the entitlements-validated flag. For example, the data protection keychain uses entitlements as part of its access control model, but refuses to honour those entitlements if the entitlement-validated flag has been cleared. Note If you’re curious about this flag, use the procinfo subcommand of launchctl to view it. For example: % sudo launchctl procinfo `pgrep Test20230126` … code signing info = valid … entitlements validated … If the flag has been cleared, this line will be missing from the code signing info section. Historically this was a serious problem because it prevented you from creating an app that uses both app groups and the data protection keychain [2] (r. 104859788). Fortunately that’s no longer an issue because the Developer website now lets you include the App Groups entitlement in macOS provisioning profiles. [1] From the perspective of macOS checking entitlements at runtime. There are other checks: The App Sandbox is mandatory for Mac App Store apps, but that’s checked when you upload the app to App Store Connect. Directly distributed apps must be notarised to pass Gatekeeper, and the notary service requires that all executables enable the hardened runtime. [2] See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. App Groups and the Keychain The differences described above explain a historical oddity associated with keychain access. The Sharing access to keychain items among a collection of apps article says: Application groups When you collect related apps into an application group using the App Groups entitlement, they share access to a group container, and gain the ability to message each other in certain ways. You can use app group names as keychain access group names, without adding them to the Keychain Access Groups entitlement. On iOS this makes a lot of sense: The App Groups entitlement is a restricted entitlement on iOS. The Developer website assigns each iOS-style app group ID to a specific team, which guarantees uniqueness. The required group. prefix means that these keychain access groups can’t collide with other keychain access groups, which all start with an App ID prefix (there’s also Apple-only keychain access groups that start with other prefixes, like apple). However, this didn’t work on macOS [1] because the App Groups entitlement is unrestricted there. However, with the Feb 2025 changes it should now be possible to use an iOS-style app group ID as a keychain access group on macOS. Note I say “should” because I’ve not actually tried it (-: Keep in mind that standard keychain access groups are protected the same way on all platforms, using the restricted Keychain Access Groups entitlement (keychain-access-groups). [1] Except for Mac Catalyst apps and iOS Apps on Mac. Not Entirely Unsatisfied When you launch a Mac app that uses app groups you might see this log entry: type: error time: 10:41:35.858009+0000 process: taskgated-helper subsystem: com.apple.ManagedClient category: ProvisioningProfiles message: com.example.apple-samplecode.Test92322409: Unsatisfied entitlements: com.apple.security.application-groups Note The exact format of that log entry, and the circumstances under which it’s generated, varies by platform. On macOS 13.0.1 I was able to generate it by running a sandboxed app that claims a macOS-style app group ID in the App Groups entitlement and also claims some other restricted entitlement. This looks kinda worrying and can be the source of problems. It means that the App Groups entitlement claims an entitlement that’s not authorised by a provisioning profile. On iOS this would trap, but on macOS the system allows the process to continue running. It does, however, clear the entitlements-validate flag. See Entitlements-Validated Flag for an in-depth discussion of this. The easiest way to avoid this problem is to authorise your app group ID claims with a provisioning profile. If there’s some reason you can’t do that, watch out for potential problems with: The data protection keychain — See the discussion of that in the Entitlements-Validated Flag and App Groups and the Keychain sections, both above. App group container protection — See App Group Container Protection, below. App Group Container Protection macOS 15 introduced app group container protection. To access an app group container without user intervention: Claim access to the app group by listing its ID in the App Groups entitlement. Locate the container by calling the containerURL(forSecurityApplicationGroupIdentifier:) method. Ensure that at least one of the following criteria are met: Your app is deployed via the Mac App Store (A). Or via TestFlight when running on macOS 15.1 or later (B). Or the app group ID starts with your app’s Team ID (C). Or your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D) [1]. If your app doesn’t follow these rules, the system prompts the user to approve its access to the container. If granted, that consent applies only for the duration of that app instance. For more on this, see: The System Integrity Protection section of the macOS Sequoia 15 Release Notes The System Integrity Protection section of the macOS Sequoia 15.1 Release Notes WWDC 2024 Session 10123 What’s new in privacy, starting at 12:23 The above criteria mean that you rarely run into the app group authorisation prompt. If you encounter a case where that happens, feel free to start a thread here on DevForums. See the top of this post for info on the topic and tags to use. Note Prior to the Feb 2025 change, things generally worked out fine when you app was deployed but you might’ve run into problems during development. That’s no longer the case. [1] This is what allows Mac Catalyst and iOS Apps on Mac to work. Revision History 2025-08-12 Added a reference to the Register App Groups build setting. 2025-07-28 Updated the Crossing the Streams section for the Jun 2025 change. Made other minor editorial changes. 2025-04-16 Rewrote the document now that iOS-style app group IDs are fully supported on the Mac. Changed the title from App Groups: macOS vs iOS: Fight! to App Groups: macOS vs iOS: Working Towards Harmony 2025-02-25 Fixed the Xcode version number mentioned in yesterday’s update. 2025-02-24 Added a quick update about the iOS-style app group IDs on macOS issue. 2024-11-05 Further clarified app group container protection. Reworked some other sections to account for this new reality. 2024-10-29 Clarified the points in App Group Container Protection. 2024-10-23 Fleshed out the discussion of app group container protection on macOS 15. 2024-09-04 Added information about app group container protection on macOS 15. 2023-01-31 Renamed the Not Entirely Unsatisfactory section to Not Entirely Unsatisfied. Updated it to describe the real impact of that log message. 2022-12-12 First posted.

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?

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.

Confirmation on "Sign in with Apple JS" Web Implementation Compatibility Hello Developers We are trying to implement "Sign in with Apple JS" on our e-commerce website, which is built on a SaaS platform called Ticimax in Turkey. Our platform provider (Ticimax) claims that a web-based implementation of "Sign in with Apple" is not currently possible. They state this is due to "Apple's browser security policies" that prevent consistent and secure support across all major browsers, particularly Safari with its privacy features. Could you please confirm if there are any fundamental security policies or technical restrictions imposed by Apple that would prevent a standard, secure implementation of "Sign in with Apple JS" on a typical e-commerce website? We know many global websites use this feature successfully. We need to know if our provider's claim has a technical basis from Apple's perspective, or if this is a standard implementation challenge that developers are expected to handle (e.g., using pop-ups instead of redirects to comply with ITP). Any official clarification or documentation you can provide on this matter would be greatly appreciated. Thank you.

Hi, Before I begin my investigation, I want to explain our code-level support process for issues related to Sign in with Apple—as the issue you’re reporting may be the result of any of the following: An error in your app or web service request. A configuration issue in your Developer Account. An internal issue in the operation system or Apple ID servers. To ensure the issue is not caused by an error within your app or web service request, please review TN3107: Resolving Sign in with Apple response errors to learn more about common error causes and potential solutions when performing requests. If the technote does not help identify the cause of the error, I need more information about your app or web services to get started. To prevent sending sensitive JSON Web Tokens (JWTs) in plain text, you should create a report in Feedback Assistant to share the details requested below. Additionally, if I determine the error is caused by an internal issue in the operating system or Apple ID servers, the appropriate engineering teams have access to the same information and can communicate with you directly for more information, if needed. Please follow the instructions below to submit your feedback. Gathering required information for troubleshooting Sign in with Apple authorization and token requests For issues occurring with your native app, perform the following steps: Install the Accounts/AuthKit profile on your iOS, macOS, tvOS, watchOS, or visionOS device. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS, macOS, tvOS, watchOS, or visionOS device. Create a report in Feedback Assistant, and ensure your feedback contains the following information: the primary App ID or Bundle ID the user’s Apple ID, email address, and/or identity token the sysdiagnose gathered after reproducing the issue the timestamp of when the issue was reproduced screenshots or videos of errors and unexpected behaviors (optional) For issues occurring with your web service, ensure your feedback contains the following information: the primary App ID and Services ID the user’s Apple ID, email address, and/or identity token the failing request, including all parameter values, and error responses (if applicable) the timestamp of when the issue was reproduced (optional) screenshots or videos of errors and unexpected behaviors (optional) Important: If providing a web service request, please ensure the client secret (JWT) has an extended expiration time (exp) of at least ten (10) business days, so I have enough time to diagnose the issue. Additionally, if your request requires access token or refresh tokens, please provide refresh tokens as they do not have a time-based expiration time; most access tokens have a maximum lifetime of one (1) hour, and will expire before I have a chance to look at the issue. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above (for your native app or web service) is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Sign in with Apple client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, I’m currently implementing App Attest attestation validation on the development server. However, I’m receiving a 403 Forbidden response when I POST a CBOR-encoded payload to the following endpoint: curl -X POST -H "Content-Type: application/cbor" --data-binary @payload.cbor 'https://data-development.appattest.apple.com' Here’s how I’m generating the CBOR payload in Java: Map&lt;String, Object&gt; payload = new HashMap&lt;&gt;(); payload.put("attestation", attestationBytes); // byte[] from DCAppAttestService payload.put("clientDataHash", clientDataHash); // SHA-256 hash of the challenge (byte[]) payload.put("keyId", keyIdBytes); // Base64-decoded keyId (byte[]) payload.put("appId", TEAM_ID + "." + BUNDLE_ID); // e.g., "ABCDE12345.com.example.app" ObjectMapper cborMapper = new ObjectMapper(new CBORFactory()); byte[] cborBody = cborMapper.writeValueAsBytes(payload); I’m unsure whether the endpoint is rejecting the payload format or if the endpoint itself is incorrect for this stage. I’d appreciate clarification on the following: 1. Is https://data-development.appattest.apple.com the correct endpoint for key attestation in a development environment? 2. Should this endpoint accept CBOR-encoded payloads, or is it only for JSON-based assertion validation? 3. Is there a current official Apple documentation that lists: • the correct URLs for key attestation and assertion validation (production and development), • or any server-side example code (e.g., Java, Python) for handling attestation/validation on the backend? So far, I couldn’t find an official document that explicitly describes the expected HTTP endpoints for these operations. If there’s a newer guide or updated API reference, I’d appreciate a link. Thanks in advance for your help.

Hello, We received a rejection on one of our IOS applications because we were doing Microsoft MSAL login through the user's browser. The representative recommended that we use Webview to do in-app logins. However when we tried to handle the custom app uri redirection (looking like myapp://auth/), Webview does not seem to send the user back to the application. Does anyone have a fix for this? Thanks!

Greetings, We are struggling to implement device binding according to your documentation. We are generation a nonce value in backend like this: public static String generateNonce(int byteLength) { byte[] randomBytes = new byte[byteLength]; new SecureRandom().nextBytes(randomBytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(randomBytes); } And our mobile client implement the attestation flow like this: @implementation AppAttestModule - (NSData *)sha256FromString:(NSString *)input { const char *str = [input UTF8String]; unsigned char result[CC_SHA256_DIGEST_LENGTH]; CC_SHA256(str, (CC_LONG)strlen(str), result); return [NSData dataWithBytes:result length:CC_SHA256_DIGEST_LENGTH]; } RCT_EXPORT_MODULE(); RCT_EXPORT_METHOD(generateAttestation:(NSString *)nonce resolver:(RCTPromiseResolveBlock)resolve rejecter:(RCTPromiseRejectBlock)reject) { if (@available(iOS 14.0, *)) { DCAppAttestService *service = [DCAppAttestService sharedService]; if (![service isSupported]) { reject(@"not_supported", @"App Attest is not supported on this device.", nil); return; } NSData *nonceData = [self sha256FromString:nonce]; NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSString *savedKeyId = [defaults stringForKey:@"AppAttestKeyId"]; NSString *savedAttestation = [defaults stringForKey:@"AppAttestAttestationData"]; void (^resolveWithValues)(NSString *keyId, NSData *assertion, NSString *attestationB64) = ^(NSString *keyId, NSData *assertion, NSString *attestationB64) { NSString *assertionB64 = [assertion base64EncodedStringWithOptions:0]; resolve(@{ @"nonce": nonce, @"signature": assertionB64, @"deviceType": @"IOS", @"attestationData": attestationB64 ?: @"", @"keyId": keyId }); }; void (^handleAssertion)(NSString *keyId, NSString *attestationB64) = ^(NSString *keyId, NSString *attestationB64) { [service generateAssertion:keyId clientDataHash:nonceData completionHandler:^(NSData *assertion, NSError *assertError) { if (!assertion) { reject(@"assertion_error", @"Failed to generate assertion", assertError); return; } resolveWithValues(keyId, assertion, attestationB64); }]; }; if (savedKeyId && savedAttestation) { handleAssertion(savedKeyId, savedAttestation); } else { [service generateKeyWithCompletionHandler:^(NSString *keyId, NSError *keyError) { if (!keyId) { reject(@"keygen_error", @"Failed to generate key", keyError); return; } [service attestKey:keyId clientDataHash:nonceData completionHandler:^(NSData *attestation, NSError *attestError) { if (!attestation) { reject(@"attestation_error", @"Failed to generate attestation", attestError); return; } NSString *attestationB64 = [attestation base64EncodedStringWithOptions:0]; [defaults setObject:keyId forKey:@"AppAttestKeyId"]; [defaults setObject:attestationB64 forKey:@"AppAttestAttestationData"]; [defaults synchronize]; handleAssertion(keyId, attestationB64); }]; }]; } } else { reject(@"ios_version", @"App Attest requires iOS 14+", nil); } } @end For validation we are extracting the nonce from the certificate like this: private static byte[] extractNonceFromAttestationCert(X509Certificate certificate) throws IOException { byte[] extensionValue = certificate.getExtensionValue("1.2.840.113635.100.8.2"); if (Objects.isNull(extensionValue)) { throw new IllegalArgumentException("Apple App Attest nonce extension not found in certificate."); } ASN1Primitive extensionPrimitive = ASN1Primitive.fromByteArray(extensionValue); ASN1OctetString outerOctet = ASN1OctetString.getInstance(extensionPrimitive); ASN1Sequence sequence = (ASN1Sequence) ASN1Primitive.fromByteArray(outerOctet.getOctets()); ASN1TaggedObject taggedObject = (ASN1TaggedObject) sequence.getObjectAt(0); ASN1OctetString nonceOctet = ASN1OctetString.getInstance(taggedObject.getObject()); return nonceOctet.getOctets(); } And for the verification we are using this method: private OptionalMethodResult<Void> verifyNonce(X509Certificate certificate, String expectedNonce, byte[] authData) { byte[] expectedNonceHash; try { byte[] nonceBytes = MessageDigest.getInstance("SHA-256").digest(expectedNonce.getBytes()); byte[] combined = ByteBuffer.allocate(authData.length + nonceBytes.length).put(authData).put(nonceBytes).array(); expectedNonceHash = MessageDigest.getInstance("SHA-256").digest(combined); } catch (NoSuchAlgorithmException e) { log.error("Error while validations iOS attestation: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } byte[] actualNonceFromCert; try { actualNonceFromCert = extractNonceFromAttestationCert(certificate); } catch (Exception e) { log.error("Error while extracting nonce from certificate: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } if (!Arrays.equals(expectedNonceHash, actualNonceFromCert)) { return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } return OptionalMethodResult.empty(); } But the values did not matched. What are we doing wrong here? Thanks.

We are implementing Platform SSO with Secure Enclave–based authentication. In a standard (post-enrollment) flow, everything behaves as expected: Authentication uses urn:ietf:params:oauth:grant-type:jwt-bearer The Secure Enclave–backed credential is used correctly However, when using Automated Device Enrollment (ADE) with Simplified Setup, we observe different behavior: After device registration, Platform SSO triggers a login request to our IdP That request uses grant_type=password Instead of the expected urn:ietf:params:oauth:grant-type:jwt-bearer This occurs even though: The configuration specifies Secure Enclave as the authentication method The same configuration works as expected outside ADE Questions: Is this password grant during ADE / Simplified Setup an expected bootstrap flow? Is there any official documentation describing this? This behavior is currently undocumented, and clarification would help ensure correct IdP implementation.

Hello Apple Team We are integrating App Attest with our backend and seeing a 400 Bad Request response when calling the attestation endpoint. The issue is that the response does not include an X-Request-ID or JSON error payload with id and code, which makes it hard to diagnose. Instead, it only returns a receipt blob. Request Details URL: https://data-development.appattest.apple.com/v1/attestationData Request Headers: Authorization: eyJraWQiOiI0RjVLSzRGV1JaIiwidHlwIjoiSldUIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJOOVNVR1pNNjdRIiwiZXhwIjoxNzU3MDUxNTYwLCJpYXQiOjE3NTcwNDc5NjB9.MEQCIF236MqPCl6Vexg7RcPUMK8XQeACXogldnpuiNnGQnzgAiBQqASdbJ64g58xfWGpbzY3iohvxBSO5U5ZE3l87JjfmQ Content-Type: application/octet-stream Request Body: (Binary data, logged as [B@59fd7d35) Response Status: 400 Bad Request Response Headers: Date: Fri, 05 Sep 2025 04:52:40 GMT x-b3-traceid: 4c42e18094022424 x-b3-spanid: 4c42e18094022424 Response Body (truncated): "receipt": h'308006092A864886F70D01070... Problem The response does not include X-Request-ID. The response does not include JSON with id or code. Only a receipt blob is returned. Questions Can the x-b3-traceid be used by Apple to trace this failed request internally? Is it expected for some failures to return only a receipt blob without X-Request-ID? How should we interpret this error so we can handle it properly in production? Thanks in advance for your guidance.

I am not able to use Feedback because the app can not reset my password.

I would like to make an app that uses Sign in with Apple to provide the users with a very convenient way of authenticating their (anonymous) identity. I'm using the identityToken that the SignInWithAppleButton provides to the onCompletion closure to build an AWS Identity Resolver that will be used to access AWS resources for that user. At the moment, everything works fine, except that the identityToken eventually stops working (I think after 24 hours) and is no longer usable for AWS identity resolvers. Is there a way to refresh the identityToken, or to generate a new one, without user interaction? I don't mind at all, if in some situations (eg logout from another device, deletion of account, etc), it cannot refresh the token, and it directs me to take further action by giving an error. Most importantly, I don't want the user to be forced to deal with the SignInWithAppleButton every time that they interact with web services. From the user's point of view, I would like the experience to be that they simply confirm that they agree to use SignInWithApple on first use (maybe once per device), and are never inconvenienced by it again. P.S. Sorry for posting this here. I tried to set the topic to "Privacy & Security" and ran into form validation errors.

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 ?

Hi all, I've on high alert after hearing about the security concerns with npm. Full disclosure, I'm new to computer and network architecture, however, as someone who is on high alert for aplications exfiltrating data or poisioning my on-device machine learning models — I've seen some things I can't fully explain and I'm hoping the community can help. I ran the code odutil show all and I was wondering why certain node names are hidden in my system and when I use the directory utility, I can't use my computer login and password to authenticate to see the users? Am I being locked out of seeing my own system? I'm trying to dig to see if a root kit was installed on my device. Does anyone know what the users and groups in the directory utility are? Who is "nobody" and who is "Unknown user"? I'll probably have a lot more questions about this suspicious files I've seen on my device. Does anyone else's device download machine learning model payloads from the internet without notifying the user (even through a firewall, no startup applications?). I've also tried deleting applications I no longer need anymore and my "system" makes them re-appear.... what?

Hello, I am currently implementing a biometric authentication registration flow using WebAuthn. I am using ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest, and I would like to know if there is a way to hide the "Save to another device" option that appears during the registration process. Specifically, I want to guide users to save the passkey only locally on their device, without prompting them to save it to iCloud Keychain or another device. If there is a way to hide this option or if there is a recommended approach to achieve this, I would greatly appreciate your guidance. Also, if this is not possible due to iOS version or API limitations, I would be grateful if you could share any best practices for limiting user options in this scenario. If anyone has experienced a similar issue, your advice would be very helpful. Thank you in advance.