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

Created

Privacy & Security Resources
General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"
0
0
579
Jul ’25
same passkey synced on 2 devices generate different prf outputs for the same salt
Steps to reproduce: register a passkey on device A authenticate on device A, using the prf extension and a constant salt. Note the prf output go to device B. wait for iCloud sync authenticate on device B using the prf extension and the same constant salt. Note the prf output The prf outputs are different. Note: Repeat the authentication on each device. The prf output is identical for a given device, which seems to point towards the inclusion of a device specific component in the prf derivation. In my scenario, I need the prf output to be the same regardless of the device since I use it as the recovery key for my app data. Could you confirm that this is the expected behavior or not? Thanks,
0
0
32
18h
ASAuthorizationProviderExtensionAuthorizationRequest caller identity behind ASWebAuthenticationSession
Can a macOS Platform SSO extension reliably identify the original app behind a Safari or ASWebAuthenticationSession-mediated request, or does ASAuthorizationProviderExtensionAuthorizationRequest only expose the immediate caller such as Safari ? We are seeing: callerBundleIdentifier = com.apple.Safari callerTeamIdentifier = Apple audit-token-based validation also resolves to Safari So the question is whether this is the expected trust model, and if so, what Apple-recommended mechanism should be used to restrict SSO participation to approved apps when the flow is browser-mediated.
0
0
39
3d
SecItemCopyMatching returns errSecAuthFailed (-25293) after macOS 26.4 upgrade — persists until SecKeychainLock/Unlock
We've filed FB22448572 for this, but posting here in case others are hitting the same issue. After upgrading macOS from 26.3.2 to 26.4, SecItemCopyMatching returns errSecAuthFailed (-25293) when reading kSecClassGenericPassword items from the default login keychain. The keychain reports as unlocked, but all authenticated operations fail. The error doesn't self-resolve — we've observed it persisting for 7+ minutes across repeated calls and process restarts. The only workaround we've found is SecKeychainLock(nil) followed by SecKeychainUnlock(nil, 0, nil, false), which prompts the user for their password and clears the stale state. Apple's own security CLI tool also fails while the keychain is in this state: $ security show-keychain-info ~/Library/Keychains/login.keychain-db security: SecKeychainCopySettings .../login.keychain-db: The user name or passphrase you entered is not correct. The trigger seems to be process lifecycle — a new process accessing the keychain early in startup (e.g., from the app delegate) can hit this state after the OS upgrade. It's probabilistic: not every machine and not every restart, but once it happens, it sticks until manual intervention. We're an enterprise app using legacy keychain APIs (SecKeychainCopyDefault, kSecUseKeychain) deployed to thousands of managed devices. We've reproduced this on multiple machines (M1, M2) and have reports from customers in the field after the 26.4 upgrade. I noticed a possibly related thread — Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4 — where SecKeychainUnlock stopped properly validating passwords after 26.4. Our symptom is different (reads fail on an unlocked keychain rather than unlock succeeding with wrong password), but both appeared after 26.4 and both point to something changing in securityd's authentication handling. Wondering if these could be related. A couple of questions: Is there a known issue with securityd's keychain authentication after 26.4? Could this be related to the CVE-2026-28864 fix ("improved permissions checking" in the Security component)? Would migrating to the data protection keychain (kSecAttrAccessible instead of kSecUseKeychain) avoid this class of issue entirely? Is there a way to detect and clear this stale state programmatically without the user entering their password? Any guidance appreciated.
1
0
209
3d
Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4
Hi, In the app I’m working on, we rely on SecKeychainUnlock to verify that a password can be used to unlock the login keychain. When macOS 26.4 rolled out, we started getting bug reports that led me to a discovery that makes me think SecKeychainUnlock behavior was changed. I’m going to illustrate my findings with a sample code: #include <pwd.h> #include <stdio.h> #include <string.h> #include <unistd.h> #include <Security/SecKeychain.h> #pragma clang diagnostic ignored "-Wdeprecated-declarations" int main(void) { char password[100]; printf("password: "); scanf("%s", password); struct passwd *home = getpwuid(getuid()); if (!(home && home->pw_dir)) return 1; char path[1024]; strcat(path, home->pw_dir); strcat(path, "/Library/Keychains/login.keychain-db"); SecKeychainRef keychain = NULL; OSStatus result = SecKeychainOpen(path, &keychain); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainOpen failed (error %d)\n", result); return 1; } SecKeychainStatus status = 0; result = SecKeychainGetStatus(keychain, &status); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainGetStatus failed (error %d)\n", result); return 1; } if (status & kSecUnlockStateStatus) { printf("keychain is unlocked, will try to lock first\n"); result = SecKeychainLock(keychain); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainLock failed (error %d)\n", result); return 1; } printf("SecKeychainLock succeeded\n"); } else { printf("keychain is locked\n"); } result = SecKeychainUnlock(keychain, strlen(password), password, TRUE); if (result == errSecSuccess) { printf("SecKeychainUnlock succeeded\n"); printf("password '%s' appears to be valid\n", password); } else { printf("SecKeychainUnlock failed (error %d)\n", result); printf("password '%s' appears to be invalid\n", password); } return 0; } Here are the outputs of this program on a machine running macOS 26.3 when provided with a correct password deadbeef and with an incorrect password foobar: testuser1@tahoe1 kcdebug % ./kcdebug password: deadbeef keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'deadbeef' appears to be valid testuser1@tahoe1 kcdebug % ./kcdebug password: foobar keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock failed (error -25293) password 'foobar' appears to be invalid And here are the outputs of this program on a machine running macOS 26.4: testuser1@tahoe2 kcdebug % ./kcdebug password: deadbeef keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'deadbeef' appears to be valid testuser1@tahoe2 kcdebug % ./kcdebug password: foobar keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'foobar' appears to be valid I’m prepared to send a feedback with Feedback Assistant, but I would like to get a confirmation that this is indeed a bug and not an intended change in behavior. I would also like to know what are my options now. SecKeychainUnlock is just a means to an end; what I really need is the ability to keep the keychain password in sync with the user password when the latter is changed by our program. Thanks in advance.
4
1
401
5d
Using mTLS with YubiKey via USB-C and PIV
I've been trying over the past few days to use a PIV-programmed Yubikey to perform mTLS (i.e. mutual client cert auth) in my custom app. My understanding is that I need to feed NSURLSession a SecIdentity to do so. Yubico's instructions state that I need their Yubico Authenticator app for this, but this directly contradicts Apple's own documentation here. I dont need NFC/lightening support, and I only need support for my specific app. When I plug in my key to my iPhone and have TKTokenWatcher active, I DO see "com.apple.pivtoken" appear in the logs. And using Yubico's SDK, I CAN get data from the key (so I'm pretty sure my entitlements and such are correct). But using the below query to get the corresponding (fake? temporary?) keychain item, it returns NULL no matter what I do: let query: [String: Any] = [ kSecClass as String: kSecClassIdentity, kSecReturnRef as String: true, kSecAttrTokenID as String: "apple.com.pivtoken", // Essential for shared iPads kSecMatchLimit as String: kSecMatchLimitOne ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) "status" is always -25300 (which is "not found"). I've also created a CTK extension (as Yubico's authenticator does) and tried to use self.keychainContents.fill(), and then tried to access it with kSecAttrTokenID as ":Yubico YubiKey OTP+FIDO+CCID", as that's what shows via TKTokenWatcher, and this also doesn't work. I've also tried just the app extension ID, and that doesn't work. Both my extension and my main app have the following entitlements: <key>com.apple.developer.default-data-protection</key> <string>NSFileProtectionComplete</string> <key>com.apple.security.application-groups</key> <array/> <key>com.apple.security.smartcard</key> <true/> <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)com.apple.pivtoken</string> <string>$(AppIdentifierPrefix)myAppExtensionId</string> </array> As one final test, I tried using the yubikey in safari to access my server using mTLS, and it works! I get prompted for a PIN (which is odd because I've programmed it not to require a PIN), but the request succeeds using the key's default PIN. I just cannot get it working with my own app. Can anyone here (or preferably, at Apple) point me in the right direction? I have a feeling that the documentation I've been reading applies to MacOS, and that iOS/ipadOS have their own restrictions that I either need to work around, or which prevent me from doing what I need to do. It's obviously possible (i.e. the Yubico Authenticator sort of does what I need it to), but not in the way that Apple seems to describe in their own documentation.
5
0
343
5d
Xcode 26.x + iOS 26.x MTE Compatibility Feedback
Xcode 26.x + iOS 26.x MTE Compatibility Feedback Reporter:Third-party App Developer Date:2026 Environments:Xcode 26.2 / 26.4, iOS 26.2 / 26.4 SDK, iPhone 17 Pro, Third-party App (Swift/C++/Python/Boost) Core Issue MTE (Memory Tagging Extension) under Memory Integrity Enforcement generates extensive false positives for valid high-performance memory operations in third-party apps, causing crashes. No official configuration exists to bypass these false positives, severely impacting stability and development costs. Key Problems 1. Widespread False Positives (Valid Code Crashes) After enabling MTE (Soft/Hard Mode), legitimate industrial-standard operations crash: Swift/ C++ containers: Array.append, resize, std::vector reallocation Custom memory pools / Boost lockfree queues:no UAF/corruption Memory reallocation:Legitimate free-reuse patterns are judged as tag mismatches. 2. MTE Hard Mode Incompatibility iOS 26.4 opens MTE Hard Mode for third-party apps, but it immediately crashes apps using standard high-performance memory management. No whitelist/exception mechanism for third-party developers. 3. MTE Soft Mode Limitations Detects far fewer issues than actual memory corruption reports. Only generates 1 simulated report per process, hiding multiple potential issues. Impact Stability: Apps crash in production when MTE is enabled. Cost: Massive code changes required to abandon memory pools/lockfree structures for system malloc. Ecosystem: Popular libraries (Python, Boost) are incompatible. Recommendations Optimize MTE rules: Add system-level exceptions for valid container resizing and memory pool operations. Provide exemptions: Allow per-region/module MTE exceptions for high-performance modules. Support runtimes: Officially support common third-party runtimes (Python/Boost) or provide system-level exemptions. Improve debugging: Increase MTE Soft Mode coverage and allow multiple reports per process.
2
0
91
6d
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?
0
0
51
6d
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?
0
0
67
6d
[KeyChain Framework] KeyChain Item is accessible post App Transfer without rebuilding the KeyChain
We have utilised the KeyChain Framework for Adding items into KeyChain. We have Generated KeyPair using 'SecKeyGeneratePair' API as below (OSStatus)generateAssymetricKeyPair:(NSUInteger)bitSize{ OSStatus sanityCheck = noErr; SecKeyRef publicKeyRef = NULL; SecKeyRef privateKeyRef = NULL; NSString *appGrpIdentifier = @"group.com.sample.xyz" // Set the private key attributes. NSDictionary *privateKeyAttr = @{(id)kSecAttrIsPermanent: @YES, (id)kSecAttrApplicationTag: [TAG_ASSYMETRIC_PRIVATE_KEY dataUsingEncoding:NSUTF8StringEncoding], (id)kSecAttrCanEncrypt:@NO, (id)kSecAttrCanDecrypt:@YES, (id)kSecAttrAccessGroup: appGrpIdentifier }; // Set the public key attributes. NSDictionary *publicKeyAttr = @{(id)kSecAttrIsPermanent: @YES, (id)kSecAttrApplicationTag: [TAG_ASSYMETRIC_PUBLIC_KEY dataUsingEncoding:NSUTF8StringEncoding], (id)kSecAttrCanEncrypt:@YES, (id)kSecAttrCanDecrypt:@NO, (id)kSecAttrAccessGroup: appGrpIdentifier }; // Set top level attributes for the keypair. NSDictionary *keyPairAttr = @{(id)kSecAttrKeyType: (id)kSecAttrKeyTypeRSA, (id)kSecAttrKeySizeInBits: @(bitSize), (id)kSecClass: (id)kSecClassKey, (id)kSecPrivateKeyAttrs: privateKeyAttr, (id)kSecPublicKeyAttrs: publicKeyAttr, // MOBSF-WARNING-SUPPRESS: (id)kSecAttrAccessible: (id)kSecAttrAccessibleAfterFirstUnlock, // mobsf-ignore: ios_keychain_weak_accessibility_value // MOBSF-SUPPRESS-END (id)kSecAttrAccessGroup: appGrpIdentifier }; // Generate Assymetric keys sanityCheck = SecKeyGeneratePair((CFDictionaryRef)keyPairAttr, &publicKeyRef, &privateKeyRef); if(sanityCheck == errSecSuccess){ NSLog(@"[DB_ENCRYPTION] <ALA_INFO> [OS-CCF] CALLED Assymetric keys are generated"); } else{ NSLog(@"[DB_ENCRYPTION] <ALA_ERROR> [OS-CCF] CALLED Error while generating asymetric keys : %d", (int)sanityCheck); } if (publicKeyRef) { CFRelease(publicKeyRef); } if (privateKeyRef) { CFRelease(privateKeyRef); } return sanityCheck; } KeyPair is added into the KeyChain (BOOL)saveSymetricKeyToKeychain:(NSData *)symmetricKeyData keyIdentifier:(NSString *)keyIdentifier { NSString *appGrpIdentifier = [KeychainGroupManager getAppGroupIdentifier]; NSDictionary *query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassKey, (__bridge id)kSecAttrApplicationTag: keyIdentifier, (__bridge id)kSecValueData: symmetricKeyData, (__bridge id)kSecAttrKeyClass: (__bridge id)kSecAttrKeyClassSymmetric, // MOBSF-WARNING-SUPPRESS: (__bridge id)kSecAttrAccessible: (__bridge id)kSecAttrAccessibleAfterFirstUnlock, // mobsf-ignore: ios_keychain_weak_accessibility_value // MOBSF-SUPPRESS-END (__bridge id)kSecAttrAccessGroup: appGrpIdentifier }; // Now add the key to the Keychain status = SecItemAdd((__bridge CFDictionaryRef)query, NULL); if (status == errSecSuccess) { NSLog(@"[DB_ENCRYPTION] Key successfully stored in the Keychain"); return YES; } else { NSLog(@"<ALA_ERROR> [DB_ENCRYPTION] Error storing key in the Keychain: %d", (int)status); return NO; } } Post App Transfer, we are able to retrieve the Public & Private Key Reference without rebuilding the keychain Query:- Is this attribute "kSecAttrAccessGroup" helping us to retrieve the KeyChain items without having to rebuild on App Transfer to New Apple Account as described in this set of guidelines. Could you please explain in detail on this. https://developer.apple.com/help/app-store-connect/transfer-an-app/overview-of-app-transfer Keychain sharing continues to work only until the app is updated. Therefore, you must rebuild the keychain when submitting updates. If your keychain group is defined in the Xcode project, replace it with a group created by the recipient, incorporating their Team ID for continued keychain sharing. After the update, users must re-login once as the app cannot retrieve the authentication token from the keychain.
1
0
57
6d
[Apple Sign-In] How to handle missing transfer_sub and the 60-day migration limit during App Transfer?
Hello everyone, We are currently preparing for an App Transfer to a new Apple Developer account due to a corporate merger. We are trying to figure out the best way to handle Apple Sign-In user migration and would love to get some advice on our proposed fallback plan. 📌 Current Situation We need to transfer our app's ownership to a new corporate entity. The app heavily relies on Apple Sign-In. The Issue: We did not collect the transfer_sub values during our initial development phase. Although we started collecting them recently, we will not have them for all existing users by the time the transfer happens. 🚨 The Risk (The 60-Day Rule) Based on Apple's documentation, even if we provide the transfer_sub, users must log into the app within 60 days of the transfer to successfully migrate their accounts. This means that users who log in after 60 days, or those whose transfer_sub is missing, will fail the Apple migration process. They will be treated as "new users" and will lose access to their existing account data. 💡 Our Proposed Custom Recovery Flow Since we cannot rely entirely on Apple's automated migration, we are planning to build a custom internal account recovery process to prevent user drop-off: A user (who failed the migration or logged in after 60 days) attempts to use Apple Sign-In on the transferred app. Since the existing account isn't linked, Apple generates a new identifier (sub), and the user enters the new sign-up flow. During the sign-up process, we enforce a mandatory identity verification step (e.g., SMS phone number verification). We query our existing user database using this verified information. If a matching existing user is found: We interrupt the sign-up process and display a prompt: "An existing account was found. We will link your account." We then update our database by mapping the new Apple sub value to their existing account record, allowing them to log in seamlessly. ❓ My Questions App Review Risk: Could this manual mapping approach—overwriting the Apple sub on an existing account based on internal identity verification—violate any Apple guidelines or result in an App Store rejection? Shared Experiences: Has anyone dealt with missing transfer_sub values or the 60-day migration limit during an App Transfer? How did you mitigate user loss? Best Practices: Are there any alternative, safer, or more recommended workarounds for this scenario?
0
0
81
6d
ASAuthorizationProviderExtensionAuthorizationRequest.complete(httpAuthorizationHeaders:) custom header not reaching endpoint
I’m implementing a macOS Platform SSO extension using ASAuthorizationProviderExtensionAuthorizationRequest. In beginAuthorization, I intercept an OAuth authorize request and call: request.complete(httpAuthorizationHeaders: [ "x-psso-attestation": signedJWT ]) I also tested: request.complete(httpAuthorizationHeaders: [ "Authorization": "Bearer test-value" ]) From extension logs, I can confirm the request is intercepted correctly and the header dictionary passed into complete(httpAuthorizationHeaders:) contains the expected values. However: the header is not visible in browser devtools the header does not appear at the server / reverse proxy So the question is: Does complete(httpAuthorizationHeaders:) support arbitrary custom headers, or only a restricted set of authorization-related headers ? Is there something that I might be missing ? And if custom headers are not supported, is there any supported way for a Platform SSO extension to attach a normal HTTP header to the continued outbound request ?
1
0
245
1w
DCDevice last_update_time issue
We are currently experiencing an unexpected issue with the DeviceCheck query_two_bits endpoint. According to the official documentation (Accessing and Modifying Per-Device Data), the last_update_time field should represent the month and year when the bits were last modified. The Issue: For several specific device tokens, our server is receiving a last_update_time value that is set in the future. Current Date: April 2026 Returned last_update_time: 2026-12 (December 2026) Here is a response: { "body": "{\"bit0\":false,\"bit1\":true,\"last_update_time\":\"2026-12\"}", "headers": { "Server": ["Apple"], "Date": ["Thu, 02 Apr 2026 06:05:23 GMT"], "Content-Type": ["application/json; charset=UTF-8"], "Transfer-Encoding": ["chunked"], "Connection": ["keep-alive"], "X-Apple-Request-UUID": ["53e16c38-d9f7-4d58-a354-ce07a4eaa35b"], "X-Responding-Instance": ["af-bit-store-56b5b6b478-k8hnh"], "Strict-Transport-Security": ["max-age=31536000; includeSubdomains"], "X-Frame-Options": ["SAMEORIGIN"], "X-Content-Type-Options": ["nosniff"], "X-XSS-Protection": ["1; mode=block"] }, "statusCode": "OK", "statusCodeValue": 200 } Technical Details: Endpoint: https://api.development.devicecheck.apple.com/v1/query_two_bits (also occurring in Production) Response Body Example: JSON { "bit0": true, "bit1": false, "last_update_time": "2026-12" } Observations: This occurs even when our server has not sent an update_two_bits request for that specific device in the current month. Questions: Is there a known issue with the timestamp synchronization or regional database propagation for DeviceCheck? Does the last_update_time field ever represent an expiration date or any value other than the "last modified" month? Best regards,
1
0
111
1w
DeviceCheck query_two_bits returns last_update_time in the future — what could cause this?
Hi everyone, I'm integrating Apple's DeviceCheck API into my app and have run into a strange issue that I can't find documented anywhere. The Problem When I call Apple's DeviceCheck query endpoint (POST https://api.devicecheck.apple.com/v1/query_two_bits), the response occasionally returns a last_update_time value that is in the future — ahead of the current server time. Example response: { "bit0": true, "bit1": false, "last_update_time": "2026-05" // future month, not yet reached } What I've Checked My server's system clock is correctly synced via NTP The JWT token I generate uses the current timestamp for the iat field This doesn't happen on every device — only on some specific devices The issue is reproducible on the same device across multiple calls Questions Is last_update_time sourced from the device's local clock at the time update_two_bits was called? Or is it stamped server-side by Apple? Could a device with an incorrectly set system clock (set to the future) cause Apple's servers to record a future last_update_time? Is there a recommended way to validate or sanitize last_update_time on the server side to handle this edge case? Has anyone else encountered this behavior? Any known workarounds? Any insight would be greatly appreciated. Thanks!
1
0
96
1w
Production-Grade Implementation Guidance: DCError Matrices, Retry Strategies, and Simulator Testing for App Attest APIs
Hi there, We're implementing Apple's DeviceCheck App Attest for production iOS authentication. The public documentation defines DCError cases but doesn't specify which errors are expected per API method or recommend retry/remediation strategies. We need Apple's guidance to implement robust, production-aligned error handling before rollout. 1. Error Surface per API Method Question: Can you confirm the complete, officially expected set of DCError values for each method? We understand the following errors are possible across App Attest APIs: invalidKey invalidInput featureUnsupported serverUnavailable unknownSystemFailure Specifically, please confirm which errors can occur for: DCAppAttestService.generateKey() DCAppAttestService.attestKey(_:clientData:) DCAppAttestService.generateAssertion(keyID:clientData:) Are there any additional undocumented or edge-case errors we should handle? 2. Retry Strategy & Remediation Matrix Question: For each API method and error code, please help us with proposal around which errorCode is retriable, whats the remediation pre retry, retry cap and backoff strategy: Kindly also help with errors that are not covered here: Specific sub-questions: invalidKey handling: When this error occurs: Should the app delete the key and call generateKey again? Or should it fail the entire flow? serverUnavailable handling: Should we retry immediately, or wait before retrying? Is exponential backoff recommended? What's the recommended max retry count? Backoff strategy: Which errors (if any) qualify for exponential backoff? Recommended base delay, max delay, and jitter approach? When should we give up and fail the request? unknownSystemFailure: Is this retriable or should we fail? Any known causes or mitigations? 3. Simulator Testing Questions: Simulator API behavior: Can App Attest APIs be called normally on iOS Simulator? If not, is there a way to simulate for testing. Do they complete successfully with simulated attestations, or do they fail? Thanks, Nirekshitha
0
0
224
1w
SFAuthorizationPluginView
I’ve developed an authorization plug-in with a mechanism that runs an SFAuthorizationPluginView subclass and I’m facing a couple issues: - Glitch after successful login After setting kAuthorizationResultAllow in the context the user is successfully logged in and brought to the desktop but the login controls remain onscreen for a few seconds after login is complete, resulting in them being visible at the same time as the dock, menu bar and desktop.
 I’ve also tried what’s mentioned here https://developer.apple.com/forums/thread/780212 but without any luck. It’s also worth mentioning that the deinit() in my SFAuthorizationPluginView subclass never gets called when the plugin it’s loaded at the login stage but it does get called the plugin is used to re-authenticate the user after they locked their screen. - update() doesn't trigger the plugin to call view(for:) I’m trying to update the UI elements out of my control (like buttons and user avatar images) in order to have them placed at the proper position on the screen after a resize of my inner NSView. To do that I call update() but it appears that does not trigger the plugin to call view(for:) and update system UI elements placement. Is this the expected behavior? - setButton not working as expected 
I’m trying to disable the login button by calling the setButton(_:enabled:) passing a SFButtonTypeLogin as inButtonType, as suggested here: https://developer.apple.com/forums/thread/777432. When the method is called at the login screen it has no effect on the button (the one with the forward-arrow icon) but when it’s called by the plugin loaded at the ‘unlock screen’ stage it successfully disable the ‘OK’ button. - Certificate issue When trying to run a network request from the plugin loaded in the ‘unlock screen’ scenario, I always get this type of error: The certificate for this server is invalid. You might be connecting to a server that is pretending to be <<server_url>> which could put your confidential information at risk Everything works as expected when the plugin is loaded either at login screen or for authorizing an operation that requires admin privileges while the user is logged in.
1
0
93
1w
launch ASWebAuthenticationSession from single sign on extenstion
I need to launch ASWebAuthenticationSession from single sign on extension, but its not launching it might issue with anchoring window, I have create custom windo and passing it in presentanchor(for session) function, custom window is launching but ASWebAuthenticationSession browser is not launching Note - flow is like this Apple PSSO register window lauched OIDC login will happen via ASWebAuthenticationSession to get accesstoken which will use in device registration but ASWebAuthenticationSession is not launching, I am using custom scheme as redirect URI iskeywindow for custom window is always false what is right approach to achieve the goal
1
0
93
1w
iPhone 16 Datasheet
I am trying to find a datasheet containing information such as "Key Exchange / Key Agreement / Key Establishment Protocols Used", "Digital Signature Algorithms Used", "Hash Algorithms Used", etc. Any information would greatly appreciated.
1
0
75
1w
Exploring Secure Enclave–backed biometric authorization between macOS and iPhone using public APIs (FaceBridge prototype)
Hi everyone, I’ve been working on an experimental prototype called FaceBridge that explores whether Secure Enclave–backed biometric authorization can be delegated between macOS and iPhone using only public Apple APIs. The goal of the project was to better understand the architectural boundaries of cross-device trust and approval flows that resemble Apple’s built-in Touch ID / Continuity authorization experiences. FaceBridge implements a local authorization pipeline where: macOS generates a signed authorization request the request is delivered to a trusted nearby iPhone over BLE / Network framework the iPhone verifies sender identity Face ID approval is requested using LocalAuthentication the iPhone signs the approval response using Secure Enclave–backed keys macOS validates the response and unlocks a protected action Security properties currently implemented: • Secure Enclave–backed signing identities per device • cryptographic device pairing and trust persistence • replay protection using nonce + timestamp binding • structured authorization request/response envelopes • signed responder identity verification • trusted-device registry model • local encrypted transport over BLE and local network This is intentionally not attempting to intercept or replace system-level Touch ID dialogs (App Store installs, Keychain prompts, loginwindow, etc.), but instead explores what is possible within application-level authorization boundaries using public APIs only. The project is open source: https://github.com/wesleysfavarin/facebridge Technical architecture write-up: https://medium.com/@wesleysfavarin/facebridge I’m particularly interested in feedback around: • recommended Secure Enclave identity lifecycle patterns • best practices for cross-device trust persistence • LocalAuthentication usage in delegated approval scenarios • whether similar authorization models are expected to become more formally supported across Apple platforms in the future Thanks in advance for any guidance or suggestions.
1
0
126
1w
TEAM ID Prefix Keychain Access
Thanks all for reading my post. A bit of context: We just finished an app transfer to our developer account. We successfully signed and generated the new release. We are already able to roll it out in testflight were we found an issue. We store valuable data in the Keychain like Authentication tokens, once the new app is installed over the old one we are experiencing a loss of all data as the keychain become "untrusted". This is worst case scenario for us because all users will immediately lose the access to the app and hence the whole system. Questions: Is there a way to solve this issue, something like migration of the Keychain data? We came to know the standard migration path: Release a version that copies items from the old access groups to a new group based on com.apple.security.application-groups (App Groups). Wait for most users to update and run the migration. Then perform the App ID prefix change. Is this still the best method? Any improvements or new tools available since the 2022 DTS post? The problem with this is that the app is already on our account and that might need to rollback the transfer. Right? How long should we realistically wait for user migration before making the prefix change? Is there a way to measure migration completion? Thank you in advance!
1
0
154
1w
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.
0
0
113
2w
Privacy & Security Resources
General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"
Replies
0
Boosts
0
Views
579
Activity
Jul ’25
same passkey synced on 2 devices generate different prf outputs for the same salt
Steps to reproduce: register a passkey on device A authenticate on device A, using the prf extension and a constant salt. Note the prf output go to device B. wait for iCloud sync authenticate on device B using the prf extension and the same constant salt. Note the prf output The prf outputs are different. Note: Repeat the authentication on each device. The prf output is identical for a given device, which seems to point towards the inclusion of a device specific component in the prf derivation. In my scenario, I need the prf output to be the same regardless of the device since I use it as the recovery key for my app data. Could you confirm that this is the expected behavior or not? Thanks,
Replies
0
Boosts
0
Views
32
Activity
18h
ASAuthorizationProviderExtensionAuthorizationRequest caller identity behind ASWebAuthenticationSession
Can a macOS Platform SSO extension reliably identify the original app behind a Safari or ASWebAuthenticationSession-mediated request, or does ASAuthorizationProviderExtensionAuthorizationRequest only expose the immediate caller such as Safari ? We are seeing: callerBundleIdentifier = com.apple.Safari callerTeamIdentifier = Apple audit-token-based validation also resolves to Safari So the question is whether this is the expected trust model, and if so, what Apple-recommended mechanism should be used to restrict SSO participation to approved apps when the flow is browser-mediated.
Replies
0
Boosts
0
Views
39
Activity
3d
SecItemCopyMatching returns errSecAuthFailed (-25293) after macOS 26.4 upgrade — persists until SecKeychainLock/Unlock
We've filed FB22448572 for this, but posting here in case others are hitting the same issue. After upgrading macOS from 26.3.2 to 26.4, SecItemCopyMatching returns errSecAuthFailed (-25293) when reading kSecClassGenericPassword items from the default login keychain. The keychain reports as unlocked, but all authenticated operations fail. The error doesn't self-resolve — we've observed it persisting for 7+ minutes across repeated calls and process restarts. The only workaround we've found is SecKeychainLock(nil) followed by SecKeychainUnlock(nil, 0, nil, false), which prompts the user for their password and clears the stale state. Apple's own security CLI tool also fails while the keychain is in this state: $ security show-keychain-info ~/Library/Keychains/login.keychain-db security: SecKeychainCopySettings .../login.keychain-db: The user name or passphrase you entered is not correct. The trigger seems to be process lifecycle — a new process accessing the keychain early in startup (e.g., from the app delegate) can hit this state after the OS upgrade. It's probabilistic: not every machine and not every restart, but once it happens, it sticks until manual intervention. We're an enterprise app using legacy keychain APIs (SecKeychainCopyDefault, kSecUseKeychain) deployed to thousands of managed devices. We've reproduced this on multiple machines (M1, M2) and have reports from customers in the field after the 26.4 upgrade. I noticed a possibly related thread — Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4 — where SecKeychainUnlock stopped properly validating passwords after 26.4. Our symptom is different (reads fail on an unlocked keychain rather than unlock succeeding with wrong password), but both appeared after 26.4 and both point to something changing in securityd's authentication handling. Wondering if these could be related. A couple of questions: Is there a known issue with securityd's keychain authentication after 26.4? Could this be related to the CVE-2026-28864 fix ("improved permissions checking" in the Security component)? Would migrating to the data protection keychain (kSecAttrAccessible instead of kSecUseKeychain) avoid this class of issue entirely? Is there a way to detect and clear this stale state programmatically without the user entering their password? Any guidance appreciated.
Replies
1
Boosts
0
Views
209
Activity
3d
Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4
Hi, In the app I’m working on, we rely on SecKeychainUnlock to verify that a password can be used to unlock the login keychain. When macOS 26.4 rolled out, we started getting bug reports that led me to a discovery that makes me think SecKeychainUnlock behavior was changed. I’m going to illustrate my findings with a sample code: #include <pwd.h> #include <stdio.h> #include <string.h> #include <unistd.h> #include <Security/SecKeychain.h> #pragma clang diagnostic ignored "-Wdeprecated-declarations" int main(void) { char password[100]; printf("password: "); scanf("%s", password); struct passwd *home = getpwuid(getuid()); if (!(home && home->pw_dir)) return 1; char path[1024]; strcat(path, home->pw_dir); strcat(path, "/Library/Keychains/login.keychain-db"); SecKeychainRef keychain = NULL; OSStatus result = SecKeychainOpen(path, &keychain); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainOpen failed (error %d)\n", result); return 1; } SecKeychainStatus status = 0; result = SecKeychainGetStatus(keychain, &status); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainGetStatus failed (error %d)\n", result); return 1; } if (status & kSecUnlockStateStatus) { printf("keychain is unlocked, will try to lock first\n"); result = SecKeychainLock(keychain); if (result != errSecSuccess) { fprintf(stderr, "SecKeychainLock failed (error %d)\n", result); return 1; } printf("SecKeychainLock succeeded\n"); } else { printf("keychain is locked\n"); } result = SecKeychainUnlock(keychain, strlen(password), password, TRUE); if (result == errSecSuccess) { printf("SecKeychainUnlock succeeded\n"); printf("password '%s' appears to be valid\n", password); } else { printf("SecKeychainUnlock failed (error %d)\n", result); printf("password '%s' appears to be invalid\n", password); } return 0; } Here are the outputs of this program on a machine running macOS 26.3 when provided with a correct password deadbeef and with an incorrect password foobar: testuser1@tahoe1 kcdebug % ./kcdebug password: deadbeef keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'deadbeef' appears to be valid testuser1@tahoe1 kcdebug % ./kcdebug password: foobar keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock failed (error -25293) password 'foobar' appears to be invalid And here are the outputs of this program on a machine running macOS 26.4: testuser1@tahoe2 kcdebug % ./kcdebug password: deadbeef keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'deadbeef' appears to be valid testuser1@tahoe2 kcdebug % ./kcdebug password: foobar keychain is unlocked, will try to lock first SecKeychainLock succeeded SecKeychainUnlock succeeded password 'foobar' appears to be valid I’m prepared to send a feedback with Feedback Assistant, but I would like to get a confirmation that this is indeed a bug and not an intended change in behavior. I would also like to know what are my options now. SecKeychainUnlock is just a means to an end; what I really need is the ability to keep the keychain password in sync with the user password when the latter is changed by our program. Thanks in advance.
Replies
4
Boosts
1
Views
401
Activity
5d
Using mTLS with YubiKey via USB-C and PIV
I've been trying over the past few days to use a PIV-programmed Yubikey to perform mTLS (i.e. mutual client cert auth) in my custom app. My understanding is that I need to feed NSURLSession a SecIdentity to do so. Yubico's instructions state that I need their Yubico Authenticator app for this, but this directly contradicts Apple's own documentation here. I dont need NFC/lightening support, and I only need support for my specific app. When I plug in my key to my iPhone and have TKTokenWatcher active, I DO see "com.apple.pivtoken" appear in the logs. And using Yubico's SDK, I CAN get data from the key (so I'm pretty sure my entitlements and such are correct). But using the below query to get the corresponding (fake? temporary?) keychain item, it returns NULL no matter what I do: let query: [String: Any] = [ kSecClass as String: kSecClassIdentity, kSecReturnRef as String: true, kSecAttrTokenID as String: "apple.com.pivtoken", // Essential for shared iPads kSecMatchLimit as String: kSecMatchLimitOne ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) "status" is always -25300 (which is "not found"). I've also created a CTK extension (as Yubico's authenticator does) and tried to use self.keychainContents.fill(), and then tried to access it with kSecAttrTokenID as ":Yubico YubiKey OTP+FIDO+CCID", as that's what shows via TKTokenWatcher, and this also doesn't work. I've also tried just the app extension ID, and that doesn't work. Both my extension and my main app have the following entitlements: <key>com.apple.developer.default-data-protection</key> <string>NSFileProtectionComplete</string> <key>com.apple.security.application-groups</key> <array/> <key>com.apple.security.smartcard</key> <true/> <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)com.apple.pivtoken</string> <string>$(AppIdentifierPrefix)myAppExtensionId</string> </array> As one final test, I tried using the yubikey in safari to access my server using mTLS, and it works! I get prompted for a PIN (which is odd because I've programmed it not to require a PIN), but the request succeeds using the key's default PIN. I just cannot get it working with my own app. Can anyone here (or preferably, at Apple) point me in the right direction? I have a feeling that the documentation I've been reading applies to MacOS, and that iOS/ipadOS have their own restrictions that I either need to work around, or which prevent me from doing what I need to do. It's obviously possible (i.e. the Yubico Authenticator sort of does what I need it to), but not in the way that Apple seems to describe in their own documentation.
Replies
5
Boosts
0
Views
343
Activity
5d
Xcode 26.x + iOS 26.x MTE Compatibility Feedback
Xcode 26.x + iOS 26.x MTE Compatibility Feedback Reporter:Third-party App Developer Date:2026 Environments:Xcode 26.2 / 26.4, iOS 26.2 / 26.4 SDK, iPhone 17 Pro, Third-party App (Swift/C++/Python/Boost) Core Issue MTE (Memory Tagging Extension) under Memory Integrity Enforcement generates extensive false positives for valid high-performance memory operations in third-party apps, causing crashes. No official configuration exists to bypass these false positives, severely impacting stability and development costs. Key Problems 1. Widespread False Positives (Valid Code Crashes) After enabling MTE (Soft/Hard Mode), legitimate industrial-standard operations crash: Swift/ C++ containers: Array.append, resize, std::vector reallocation Custom memory pools / Boost lockfree queues:no UAF/corruption Memory reallocation:Legitimate free-reuse patterns are judged as tag mismatches. 2. MTE Hard Mode Incompatibility iOS 26.4 opens MTE Hard Mode for third-party apps, but it immediately crashes apps using standard high-performance memory management. No whitelist/exception mechanism for third-party developers. 3. MTE Soft Mode Limitations Detects far fewer issues than actual memory corruption reports. Only generates 1 simulated report per process, hiding multiple potential issues. Impact Stability: Apps crash in production when MTE is enabled. Cost: Massive code changes required to abandon memory pools/lockfree structures for system malloc. Ecosystem: Popular libraries (Python, Boost) are incompatible. Recommendations Optimize MTE rules: Add system-level exceptions for valid container resizing and memory pool operations. Provide exemptions: Allow per-region/module MTE exceptions for high-performance modules. Support runtimes: Officially support common third-party runtimes (Python/Boost) or provide system-level exemptions. Improve debugging: Increase MTE Soft Mode coverage and allow multiple reports per process.
Replies
2
Boosts
0
Views
91
Activity
6d
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
0
Boosts
0
Views
51
Activity
6d
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
0
Boosts
0
Views
67
Activity
6d
[KeyChain Framework] KeyChain Item is accessible post App Transfer without rebuilding the KeyChain
We have utilised the KeyChain Framework for Adding items into KeyChain. We have Generated KeyPair using 'SecKeyGeneratePair' API as below (OSStatus)generateAssymetricKeyPair:(NSUInteger)bitSize{ OSStatus sanityCheck = noErr; SecKeyRef publicKeyRef = NULL; SecKeyRef privateKeyRef = NULL; NSString *appGrpIdentifier = @"group.com.sample.xyz" // Set the private key attributes. NSDictionary *privateKeyAttr = @{(id)kSecAttrIsPermanent: @YES, (id)kSecAttrApplicationTag: [TAG_ASSYMETRIC_PRIVATE_KEY dataUsingEncoding:NSUTF8StringEncoding], (id)kSecAttrCanEncrypt:@NO, (id)kSecAttrCanDecrypt:@YES, (id)kSecAttrAccessGroup: appGrpIdentifier }; // Set the public key attributes. NSDictionary *publicKeyAttr = @{(id)kSecAttrIsPermanent: @YES, (id)kSecAttrApplicationTag: [TAG_ASSYMETRIC_PUBLIC_KEY dataUsingEncoding:NSUTF8StringEncoding], (id)kSecAttrCanEncrypt:@YES, (id)kSecAttrCanDecrypt:@NO, (id)kSecAttrAccessGroup: appGrpIdentifier }; // Set top level attributes for the keypair. NSDictionary *keyPairAttr = @{(id)kSecAttrKeyType: (id)kSecAttrKeyTypeRSA, (id)kSecAttrKeySizeInBits: @(bitSize), (id)kSecClass: (id)kSecClassKey, (id)kSecPrivateKeyAttrs: privateKeyAttr, (id)kSecPublicKeyAttrs: publicKeyAttr, // MOBSF-WARNING-SUPPRESS: (id)kSecAttrAccessible: (id)kSecAttrAccessibleAfterFirstUnlock, // mobsf-ignore: ios_keychain_weak_accessibility_value // MOBSF-SUPPRESS-END (id)kSecAttrAccessGroup: appGrpIdentifier }; // Generate Assymetric keys sanityCheck = SecKeyGeneratePair((CFDictionaryRef)keyPairAttr, &publicKeyRef, &privateKeyRef); if(sanityCheck == errSecSuccess){ NSLog(@"[DB_ENCRYPTION] <ALA_INFO> [OS-CCF] CALLED Assymetric keys are generated"); } else{ NSLog(@"[DB_ENCRYPTION] <ALA_ERROR> [OS-CCF] CALLED Error while generating asymetric keys : %d", (int)sanityCheck); } if (publicKeyRef) { CFRelease(publicKeyRef); } if (privateKeyRef) { CFRelease(privateKeyRef); } return sanityCheck; } KeyPair is added into the KeyChain (BOOL)saveSymetricKeyToKeychain:(NSData *)symmetricKeyData keyIdentifier:(NSString *)keyIdentifier { NSString *appGrpIdentifier = [KeychainGroupManager getAppGroupIdentifier]; NSDictionary *query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassKey, (__bridge id)kSecAttrApplicationTag: keyIdentifier, (__bridge id)kSecValueData: symmetricKeyData, (__bridge id)kSecAttrKeyClass: (__bridge id)kSecAttrKeyClassSymmetric, // MOBSF-WARNING-SUPPRESS: (__bridge id)kSecAttrAccessible: (__bridge id)kSecAttrAccessibleAfterFirstUnlock, // mobsf-ignore: ios_keychain_weak_accessibility_value // MOBSF-SUPPRESS-END (__bridge id)kSecAttrAccessGroup: appGrpIdentifier }; // Now add the key to the Keychain status = SecItemAdd((__bridge CFDictionaryRef)query, NULL); if (status == errSecSuccess) { NSLog(@"[DB_ENCRYPTION] Key successfully stored in the Keychain"); return YES; } else { NSLog(@"<ALA_ERROR> [DB_ENCRYPTION] Error storing key in the Keychain: %d", (int)status); return NO; } } Post App Transfer, we are able to retrieve the Public & Private Key Reference without rebuilding the keychain Query:- Is this attribute "kSecAttrAccessGroup" helping us to retrieve the KeyChain items without having to rebuild on App Transfer to New Apple Account as described in this set of guidelines. Could you please explain in detail on this. https://developer.apple.com/help/app-store-connect/transfer-an-app/overview-of-app-transfer Keychain sharing continues to work only until the app is updated. Therefore, you must rebuild the keychain when submitting updates. If your keychain group is defined in the Xcode project, replace it with a group created by the recipient, incorporating their Team ID for continued keychain sharing. After the update, users must re-login once as the app cannot retrieve the authentication token from the keychain.
Replies
1
Boosts
0
Views
57
Activity
6d
[Apple Sign-In] How to handle missing transfer_sub and the 60-day migration limit during App Transfer?
Hello everyone, We are currently preparing for an App Transfer to a new Apple Developer account due to a corporate merger. We are trying to figure out the best way to handle Apple Sign-In user migration and would love to get some advice on our proposed fallback plan. 📌 Current Situation We need to transfer our app's ownership to a new corporate entity. The app heavily relies on Apple Sign-In. The Issue: We did not collect the transfer_sub values during our initial development phase. Although we started collecting them recently, we will not have them for all existing users by the time the transfer happens. 🚨 The Risk (The 60-Day Rule) Based on Apple's documentation, even if we provide the transfer_sub, users must log into the app within 60 days of the transfer to successfully migrate their accounts. This means that users who log in after 60 days, or those whose transfer_sub is missing, will fail the Apple migration process. They will be treated as "new users" and will lose access to their existing account data. 💡 Our Proposed Custom Recovery Flow Since we cannot rely entirely on Apple's automated migration, we are planning to build a custom internal account recovery process to prevent user drop-off: A user (who failed the migration or logged in after 60 days) attempts to use Apple Sign-In on the transferred app. Since the existing account isn't linked, Apple generates a new identifier (sub), and the user enters the new sign-up flow. During the sign-up process, we enforce a mandatory identity verification step (e.g., SMS phone number verification). We query our existing user database using this verified information. If a matching existing user is found: We interrupt the sign-up process and display a prompt: "An existing account was found. We will link your account." We then update our database by mapping the new Apple sub value to their existing account record, allowing them to log in seamlessly. ❓ My Questions App Review Risk: Could this manual mapping approach—overwriting the Apple sub on an existing account based on internal identity verification—violate any Apple guidelines or result in an App Store rejection? Shared Experiences: Has anyone dealt with missing transfer_sub values or the 60-day migration limit during an App Transfer? How did you mitigate user loss? Best Practices: Are there any alternative, safer, or more recommended workarounds for this scenario?
Replies
0
Boosts
0
Views
81
Activity
6d
ASAuthorizationProviderExtensionAuthorizationRequest.complete(httpAuthorizationHeaders:) custom header not reaching endpoint
I’m implementing a macOS Platform SSO extension using ASAuthorizationProviderExtensionAuthorizationRequest. In beginAuthorization, I intercept an OAuth authorize request and call: request.complete(httpAuthorizationHeaders: [ "x-psso-attestation": signedJWT ]) I also tested: request.complete(httpAuthorizationHeaders: [ "Authorization": "Bearer test-value" ]) From extension logs, I can confirm the request is intercepted correctly and the header dictionary passed into complete(httpAuthorizationHeaders:) contains the expected values. However: the header is not visible in browser devtools the header does not appear at the server / reverse proxy So the question is: Does complete(httpAuthorizationHeaders:) support arbitrary custom headers, or only a restricted set of authorization-related headers ? Is there something that I might be missing ? And if custom headers are not supported, is there any supported way for a Platform SSO extension to attach a normal HTTP header to the continued outbound request ?
Replies
1
Boosts
0
Views
245
Activity
1w
DCDevice last_update_time issue
We are currently experiencing an unexpected issue with the DeviceCheck query_two_bits endpoint. According to the official documentation (Accessing and Modifying Per-Device Data), the last_update_time field should represent the month and year when the bits were last modified. The Issue: For several specific device tokens, our server is receiving a last_update_time value that is set in the future. Current Date: April 2026 Returned last_update_time: 2026-12 (December 2026) Here is a response: { "body": "{\"bit0\":false,\"bit1\":true,\"last_update_time\":\"2026-12\"}", "headers": { "Server": ["Apple"], "Date": ["Thu, 02 Apr 2026 06:05:23 GMT"], "Content-Type": ["application/json; charset=UTF-8"], "Transfer-Encoding": ["chunked"], "Connection": ["keep-alive"], "X-Apple-Request-UUID": ["53e16c38-d9f7-4d58-a354-ce07a4eaa35b"], "X-Responding-Instance": ["af-bit-store-56b5b6b478-k8hnh"], "Strict-Transport-Security": ["max-age=31536000; includeSubdomains"], "X-Frame-Options": ["SAMEORIGIN"], "X-Content-Type-Options": ["nosniff"], "X-XSS-Protection": ["1; mode=block"] }, "statusCode": "OK", "statusCodeValue": 200 } Technical Details: Endpoint: https://api.development.devicecheck.apple.com/v1/query_two_bits (also occurring in Production) Response Body Example: JSON { "bit0": true, "bit1": false, "last_update_time": "2026-12" } Observations: This occurs even when our server has not sent an update_two_bits request for that specific device in the current month. Questions: Is there a known issue with the timestamp synchronization or regional database propagation for DeviceCheck? Does the last_update_time field ever represent an expiration date or any value other than the "last modified" month? Best regards,
Replies
1
Boosts
0
Views
111
Activity
1w
DeviceCheck query_two_bits returns last_update_time in the future — what could cause this?
Hi everyone, I'm integrating Apple's DeviceCheck API into my app and have run into a strange issue that I can't find documented anywhere. The Problem When I call Apple's DeviceCheck query endpoint (POST https://api.devicecheck.apple.com/v1/query_two_bits), the response occasionally returns a last_update_time value that is in the future — ahead of the current server time. Example response: { "bit0": true, "bit1": false, "last_update_time": "2026-05" // future month, not yet reached } What I've Checked My server's system clock is correctly synced via NTP The JWT token I generate uses the current timestamp for the iat field This doesn't happen on every device — only on some specific devices The issue is reproducible on the same device across multiple calls Questions Is last_update_time sourced from the device's local clock at the time update_two_bits was called? Or is it stamped server-side by Apple? Could a device with an incorrectly set system clock (set to the future) cause Apple's servers to record a future last_update_time? Is there a recommended way to validate or sanitize last_update_time on the server side to handle this edge case? Has anyone else encountered this behavior? Any known workarounds? Any insight would be greatly appreciated. Thanks!
Replies
1
Boosts
0
Views
96
Activity
1w
Production-Grade Implementation Guidance: DCError Matrices, Retry Strategies, and Simulator Testing for App Attest APIs
Hi there, We're implementing Apple's DeviceCheck App Attest for production iOS authentication. The public documentation defines DCError cases but doesn't specify which errors are expected per API method or recommend retry/remediation strategies. We need Apple's guidance to implement robust, production-aligned error handling before rollout. 1. Error Surface per API Method Question: Can you confirm the complete, officially expected set of DCError values for each method? We understand the following errors are possible across App Attest APIs: invalidKey invalidInput featureUnsupported serverUnavailable unknownSystemFailure Specifically, please confirm which errors can occur for: DCAppAttestService.generateKey() DCAppAttestService.attestKey(_:clientData:) DCAppAttestService.generateAssertion(keyID:clientData:) Are there any additional undocumented or edge-case errors we should handle? 2. Retry Strategy & Remediation Matrix Question: For each API method and error code, please help us with proposal around which errorCode is retriable, whats the remediation pre retry, retry cap and backoff strategy: Kindly also help with errors that are not covered here: Specific sub-questions: invalidKey handling: When this error occurs: Should the app delete the key and call generateKey again? Or should it fail the entire flow? serverUnavailable handling: Should we retry immediately, or wait before retrying? Is exponential backoff recommended? What's the recommended max retry count? Backoff strategy: Which errors (if any) qualify for exponential backoff? Recommended base delay, max delay, and jitter approach? When should we give up and fail the request? unknownSystemFailure: Is this retriable or should we fail? Any known causes or mitigations? 3. Simulator Testing Questions: Simulator API behavior: Can App Attest APIs be called normally on iOS Simulator? If not, is there a way to simulate for testing. Do they complete successfully with simulated attestations, or do they fail? Thanks, Nirekshitha
Replies
0
Boosts
0
Views
224
Activity
1w
SFAuthorizationPluginView
I’ve developed an authorization plug-in with a mechanism that runs an SFAuthorizationPluginView subclass and I’m facing a couple issues: - Glitch after successful login After setting kAuthorizationResultAllow in the context the user is successfully logged in and brought to the desktop but the login controls remain onscreen for a few seconds after login is complete, resulting in them being visible at the same time as the dock, menu bar and desktop.
 I’ve also tried what’s mentioned here https://developer.apple.com/forums/thread/780212 but without any luck. It’s also worth mentioning that the deinit() in my SFAuthorizationPluginView subclass never gets called when the plugin it’s loaded at the login stage but it does get called the plugin is used to re-authenticate the user after they locked their screen. - update() doesn't trigger the plugin to call view(for:) I’m trying to update the UI elements out of my control (like buttons and user avatar images) in order to have them placed at the proper position on the screen after a resize of my inner NSView. To do that I call update() but it appears that does not trigger the plugin to call view(for:) and update system UI elements placement. Is this the expected behavior? - setButton not working as expected 
I’m trying to disable the login button by calling the setButton(_:enabled:) passing a SFButtonTypeLogin as inButtonType, as suggested here: https://developer.apple.com/forums/thread/777432. When the method is called at the login screen it has no effect on the button (the one with the forward-arrow icon) but when it’s called by the plugin loaded at the ‘unlock screen’ stage it successfully disable the ‘OK’ button. - Certificate issue When trying to run a network request from the plugin loaded in the ‘unlock screen’ scenario, I always get this type of error: The certificate for this server is invalid. You might be connecting to a server that is pretending to be <<server_url>> which could put your confidential information at risk Everything works as expected when the plugin is loaded either at login screen or for authorizing an operation that requires admin privileges while the user is logged in.
Replies
1
Boosts
0
Views
93
Activity
1w
launch ASWebAuthenticationSession from single sign on extenstion
I need to launch ASWebAuthenticationSession from single sign on extension, but its not launching it might issue with anchoring window, I have create custom windo and passing it in presentanchor(for session) function, custom window is launching but ASWebAuthenticationSession browser is not launching Note - flow is like this Apple PSSO register window lauched OIDC login will happen via ASWebAuthenticationSession to get accesstoken which will use in device registration but ASWebAuthenticationSession is not launching, I am using custom scheme as redirect URI iskeywindow for custom window is always false what is right approach to achieve the goal
Replies
1
Boosts
0
Views
93
Activity
1w
iPhone 16 Datasheet
I am trying to find a datasheet containing information such as "Key Exchange / Key Agreement / Key Establishment Protocols Used", "Digital Signature Algorithms Used", "Hash Algorithms Used", etc. Any information would greatly appreciated.
Replies
1
Boosts
0
Views
75
Activity
1w
Exploring Secure Enclave–backed biometric authorization between macOS and iPhone using public APIs (FaceBridge prototype)
Hi everyone, I’ve been working on an experimental prototype called FaceBridge that explores whether Secure Enclave–backed biometric authorization can be delegated between macOS and iPhone using only public Apple APIs. The goal of the project was to better understand the architectural boundaries of cross-device trust and approval flows that resemble Apple’s built-in Touch ID / Continuity authorization experiences. FaceBridge implements a local authorization pipeline where: macOS generates a signed authorization request the request is delivered to a trusted nearby iPhone over BLE / Network framework the iPhone verifies sender identity Face ID approval is requested using LocalAuthentication the iPhone signs the approval response using Secure Enclave–backed keys macOS validates the response and unlocks a protected action Security properties currently implemented: • Secure Enclave–backed signing identities per device • cryptographic device pairing and trust persistence • replay protection using nonce + timestamp binding • structured authorization request/response envelopes • signed responder identity verification • trusted-device registry model • local encrypted transport over BLE and local network This is intentionally not attempting to intercept or replace system-level Touch ID dialogs (App Store installs, Keychain prompts, loginwindow, etc.), but instead explores what is possible within application-level authorization boundaries using public APIs only. The project is open source: https://github.com/wesleysfavarin/facebridge Technical architecture write-up: https://medium.com/@wesleysfavarin/facebridge I’m particularly interested in feedback around: • recommended Secure Enclave identity lifecycle patterns • best practices for cross-device trust persistence • LocalAuthentication usage in delegated approval scenarios • whether similar authorization models are expected to become more formally supported across Apple platforms in the future Thanks in advance for any guidance or suggestions.
Replies
1
Boosts
0
Views
126
Activity
1w
TEAM ID Prefix Keychain Access
Thanks all for reading my post. A bit of context: We just finished an app transfer to our developer account. We successfully signed and generated the new release. We are already able to roll it out in testflight were we found an issue. We store valuable data in the Keychain like Authentication tokens, once the new app is installed over the old one we are experiencing a loss of all data as the keychain become "untrusted". This is worst case scenario for us because all users will immediately lose the access to the app and hence the whole system. Questions: Is there a way to solve this issue, something like migration of the Keychain data? We came to know the standard migration path: Release a version that copies items from the old access groups to a new group based on com.apple.security.application-groups (App Groups). Wait for most users to update and run the migration. Then perform the App ID prefix change. Is this still the best method? Any improvements or new tools available since the 2022 DTS post? The problem with this is that the app is already on our account and that might need to rollback the transfer. Right? How long should we realistically wait for user migration before making the prefix change? Is there a way to measure migration completion? Thank you in advance!
Replies
1
Boosts
0
Views
154
Activity
1w
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
0
Boosts
0
Views
113
Activity
2w