Not getting ASCredentialServiceIdentifier in func prepareOneTimeCodeCredentialList(for serviceIdentifiers: [ASCredentialServiceIdentifier]) when trying to use ASCredentialProviderViewController for autofilling one time codes in iOS 18.

Description: I am attempting to use the OpenDirectory API ODRecord.changePassword to change a user's password without needing the old password, given that I have the appropriate permissions. The goal is to ensure that the password change operation bypasses third-party tools such as EDR or eBPF apps that might otherwise intercept commands, as the operation occurs directly via the API. Problem: When invoking the OpenDirectory API from a launch daemon with root privileges, I receive the following error message: Error Domain=com.apple.OpenDirectory Code=4001 "Operation was denied because the current credentials do not have the appropriate privileges." UserInfo={NSUnderlyingError=0x135907570 {Error Domain=com.apple.OpenDirectory Code=4001 "Credential cannot update user's SecureToken" UserInfo={NSDescription=Credential cannot update user's SecureToken}}, NSLocalizedDescription=Operation was denied because the current credentials do not have the appropriate privileges., NSLocalizedFailureReason=Operation was denied because the current credentials do not have the appropriate privileges.} It seems the error is related to SecureToken, and the underlying issue is that the current credentials (even though they are root-level) do not have the necessary privileges to update the SecureToken status for the user. Steps I’ve Taken: Tested the API via a launch daemon running with root privileges. Ensured that Full Disk Access was granted to the daemon, but this did not resolve the issue. Request: Has anyone encountered this specific issue where root privileges are insufficient to update the user password via the OpenDirectory API ? What additional steps or permissions are required for a user password change? Is there a specific API or method to elevate the privileges for modifying SecureToken, or a workaround to overcome this limitation? Any insights or guidance on this issue would be greatly appreciated! Thank you in advance for your help!

Hello, We plan to remove our app from the App Store. This post aims to determine whether our company can rely on Private Relay to compensate our customers. Our Challenge: Gift Card Refunds with Private Relay Some customers purchased gift cards through our app using Apple's "Private Relay" during account creation. To process refunds, we need a way to identify these customers. Our system relies on email addresses, which are masked by Private Relay. Potential Solution: Apps Using Apple ID We're exploring "Apps Using Apple ID" as a possible solution for customers to share their Private Relay addresses for refund purposes. Under what circumstances will an app cease to appear in the "Apps Using Apple ID" list? What conditions must be met to initiate a new Private Relay connection for the same user and application? For example, would using the same Apple account to sign into the app on a different device trigger a new Private Relay? Thank you for your help!

E aí pessoal, tudo certo? Estou desenvolvendo um app com React Native no front-end e Node.js no back-end, usando o Firebase como banco de dados (e possivelmente para autenticação também, dependendo da solução). Preciso implementar o "Sign in with Apple" e estou com algumas dúvidas em como integrar tudo isso. A ideia é: o usuário clica no botão "Entrar com a Apple" no app (React Native), o backend (Node.js) processa a autenticação com a Apple e, em seguida, armazena as informações necessárias (nome, email, etc.) no Firebase. Se alguém já trabalhou com essa combinação (React Native, Node.js, Firebase e Sign in with Apple) e puder compartilhar alguma experiência, dicas, exemplos de código ou até mesmo um boilerplate, seria de grande ajuda!

Hello, I'm exploring the Secure Enclave APIs, and I'm wondering if it's possible to "cryptographically" determine if a block of data was signed on the Secure Enclave. When I sign a block of data using the Secure Enclave (which implies using a key pair automatically generated by the enclave) and distribute the public key to others, is there any way to verify if the message was encrypted on it / its private key was generated by it? In other words, what I'm trying to achieve is to make sure that the public key hasn't been tampered with until it reaches its destination (including on-device threats, since otherwise I could've used a normal keychain item, perhaps?). For the purpose of this example, I'm not necessarily interested in figuring out if the key was signed on a certain device's enclave, but rather on any Secure Enclave. So, using something derived from the enclave's GID Key (described in the Apple Platform Security guide) would work for this.

Please help me clarify the current situation regarding the necessity of a privacy manifest file in 3rd party SDKs. It would be nice to have a reply from someone working at Apple, to have a reliable answer. A quick summery of the events from last year https://developer.apple.com/support/third-party-SDK-requirements/ : "Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App Store Connect that include those SDKs, or when you submit an app update that adds one of the listed SDKs as part of the update." Last autumn, we started receiving warning emails from Apple after initiating app reviews, even when our apps did not have a newly added SDK: ITMS-91061: Missing privacy manifest - Starting November 12, 2024, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. According to this warning message, app updates which do not contain any new SDKs are still not affected. Since then, at one point in time the deadline changed, as now we have February 12, 2025 in the privacy manifest documentation: https://developer.apple.com/documentation/bundleresources/adding-a-privacy-manifest-to-your-app-or-third-party-sdk However, this page does not contain any mention of the circumstances, it only states in general that apps you submit for review in App Store Connect must contain a valid privacy manifest file for a certain number of commonly used third-party SDKs. My questions Does the February deadline apply to every app update, even if they do not contain any newly added SDKs? Or does it still affect only the app updates "that adds one of the listed SDKs as part of the update." ? If the former, the 3rd party requirements page should be updated in my opinion. And if the latter, why does the documentation not contain this important piece of information? We have a basic product which then gets customised for the clients so we upload several different apps based on the same code with the same dependencies. How is it possible that during autumn, Apple sent ITMS-91061: Missing privacy manifest warnings for some of our apps, but did not send it for others? Does Apple not validate all the apps but only some of them randomly? Also, the warning still states that it should be relevant if "an app update adds a new privacy-impacting SDK", but that was not the case for us, we did not add anything newly to our apps - why did we even get these warnings then? Just in general: when the deadlines change, is there any channel where Apple communicates these, besides the warning emails? I did not see any posts on the Apple Developer site's News page about this February date, I just found it by accident. I don't even remember seeing a notice about the original November deadline, we just started receiving the email warnings without expecting them. Thank you in advance for anyone sharing an answer.

Why does the following code generate a public key that can't be parsed by openssl? import Security import CryptoKit func generateKeys() throws -> (privateKey: SecKey, publicKey: SecKey) { let query: [String: Any] = [ kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom, kSecAttrKeySizeInBits as String: 256, kSecAttrIsPermanent as String: false ] var error: Unmanaged<CFError>? guard let privateKey = SecKeyCreateRandomKey(query as CFDictionary, &error) else { throw error!.takeRetainedValue() } let publicKey = SecKeyCopyPublicKey(privateKey)! return (privateKey, publicKey) } extension SecKey { func exportBase64EncodedKey() -> String { var error: Unmanaged<CFError>? guard let data = SecKeyCopyExternalRepresentation(self, &error) else { fatalError("Failed to export key: \(error!.takeRetainedValue())") } return (data as Data).base64EncodedString(options: [.lineLength64Characters]) } } func printPublicKey() { let keyPair = try! generateKeys() let encodedPublicKey = keyPair.publicKey.exportBase64EncodedKey() var header = "-----BEGIN PUBLIC KEY-----" var footer = "-----END PUBLIC KEY-----" var pemKey = "\(header)\n\(encodedPublicKey)\n\(footer)\n" print(pemKey) } printPublicKey() when parsing the key I get this: openssl pkey -pubin -in new_public_key.pem -text -noout Could not find private key of Public Key from new_public_key.pem 404278EC01000000:error:1E08010C:DECODER routines:OSSL_DECODER_from_bio:unsupported:crypto/encode_decode/decoder_lib.c:102:No supported data to decode. Replacing kSecAttrKeyTypeECSECPrimeRandom with kSecAttrKeyTypeRSA and a bigger key size (e.g. 2048) gives me a working public key that can be parsed by Openssl. Thanks!

I’m implementing Passkey registration on iOS using ASAuthorizationPlatformPublicKeyCredentialProvider. On the server side, I’m using a WebAuthn library that throws the error UnexpectedRPIDHash: Unexpected RP ID hash during verifyRegistrationResponse(). Domain: pebblepath.link (publicly routable, valid SSL certificate, no warnings in Safari) Associated Domains in Xcode**: webcredentials:pebblepath.link AASA file: { "applinks": { "apps": [] }, "webcredentials": { "apps": [ "H33XH8JMV6.com.reactivex.pebblepath" ] } } Xcode Configuration: Team ID: H33XH8JMV6 Bundle ID: com.reactivex.pebblepath Associated Domains: webcredentials:pebblepath.link Logs: iOS clientDataJSON shows "origin": "https://pebblepath.link". Server logs confirm expectedOrigin = "https://pebblepath.link" and expectedRPID = "pebblepath.link". Despite this, the server library still errors out: finishRegistration error: UnexpectedRPIDHash. I’ve verified that: The domain has a valid CA-signed SSL cert (no Safari warnings). The AASA file is reachable at https://pebblepath.link/.well-known/apple-app-site-association. The app’s entitlements match H33XH8JMV6.com.reactivex.pebblepath. I’ve removed old passkeys from Settings → Passwords on the device and retried fresh. I’m testing on a real device with iOS 16+; I am using a Development provisioning profile, but that shouldn’t cause an RP ID mismatch as long as the domain is valid. Every log indicates that the domain and origin match exactly, but the WebAuthn library still throws UnexpectedRPIDHash, implying iOS is embedding a different (or unrecognized) RP ID hash in the credential. Has anyone else encountered this with iOS passkeys and a valid domain/AASA setup? Is there an extra step needed to ensure iOS recognizes the domain for passkey registration? Any guidance or insights would be greatly appreciated!

I was in the webview long according to the pictures, and then select "save image" will lead to collapse, I have passed on the info plist add NSPhotoLibraryAddUsageDescription solved it. Now I have another question, does the last item "query" in the screenshot have a similar problem? Since I couldn't click the button (I don't know why this happened), I couldn't test it on the real machine.

Hi, I have a question about UIDevice identifierForVendor. I am distributing 3 apps using an enterprise account. All apps use the same developer account and certificates. The bundle IDs of the apps are as follows: com.abc.inhouse.mail com.abc.searchent com.abc.noteent In the Enterprise builds, apps 1 and 2 share the same identifierForVendor (IDFV). However, app 3 has a different IDFV value. According to Apple documentation, the IDFV is determined based on the bundle ID when distributing through Enterprise. Why does app 3 have a different IDFV? Are there any other factors besides the bundle ID that affect the IDFV in Enterprise builds? Please help me figure this out. Thank you for your time!

Is there a way to unlock login keychain without using password and with any other authentication factor supported by 3rd party MFA options?

I was testing an app with AppleSignIn with a Firebase backend and wanted to test account deletion functionality. I was unaware of needing to revoke the token with Apple before proceeding with account deletion. Now, when I try to create a new account with the same appleId email, the token passed to Firebase is invalid and the login fails. As such, I am blocked from testing my app with authenticated Apple users, so I'm trying to understand what the workaround is. Thanks in advance!

I am developing an app that uses Sign In with Apple for authentication, and I need to test different scenarios, such as when a user chooses not to share their email. However, after logging in for the first time, I cannot reset the permissions flow to test again. Even after uninstalling the app, revoking access to the Apple ID in ‘Settings > Apps Using Apple ID,’ and attempting to log in again, only the token (identityToken) is returned, while the full information (email, name, surname) is no longer provided. This makes it difficult to simulate the initial user behavior, especially when choosing to share or not share their email. I would like to know: 1. Is there a way to completely reset the permissions flow so I can test as if it were the first time using the same Apple ID? 2. Are there any recommended solutions for development scenarios without needing to create multiple Apple IDs? Thank you for any guidance on how to proceed.

Our service has ended and the app has been removed from the App store. This app supported Sign in with Apple, but even if I try to revoke the account from the iOS settings or account.apple.com on the web, but can't delete it and no error is displayed. Does anyone know the cause of this problem or have encountered it? I'm not sure if it's related, but this app was previously transferred from another organization.

I am currently working on ways my application which would monitor the dlopen() and dlsym() calls made on macOS. In the current list of events endpoint security framework provides, I don't see a relevant event which would give me this information. Are there any alternate ways we can get these events on macOS?

Hi, We came accross with 2 devices, iPhone 12 and iphone16 pro. the both have same device code. Both the devices have same apple id and belongs to same user I had understanding that device codes are unique to device. How this can happen? Any remediation? Thanks, Veena

I have add my domani and email address to Configure Sign in with Apple for Email Communication (https://developer.apple.com/account/resources/services/configure) and it pass SPF already but when it send from server that i setup is had "Error Description : Permanament error. Please do not try again, according to the information returned by the other party to confirm the specific cause of the error. Cause:550 5.1.1 : unauthorized sender" a mail service is on Alibaba Cloud the email that i want to sending to is ending with @privaterelay.appleid.com it that have any solve problem or i missing any thing else ?

I am running a service available on both an app and a web platform with "Sign In with Apple." Should I store the tokens separately, or should I overwrite them in a single storage location? When a user requests to sign out, should I revoke both the app and web tokens, or will revoking the app token automatically cover the web token as well?

Hi, We use the iOS Keychain in our mobile app to securely store and retrieve data, which is tightly coupled with the initialization of some app features within the application. This issue is encountered during app launch We retrieve during Splash Screen UI controller at viewDidApper() The logic we use to access the Keychain is as follows: NSDate *NSDate_CD; NSString *account = [NSString stringWithUTF8String:@"SOME_KEY_ACCOUNT"]; NSString *attrgen = [NSString stringWithUTF8String:@"SOME_KEY"]; NSMutableDictionary *query = [[NSMutableDictionary alloc] init]; [query setObject:(__bridge id)(kSecClassGenericPassword) forKey:(__bridge id&lt;NSCopying&gt;)(kSecClass)]; [query setObject:attrgen forKey:(__bridge id&lt;NSCopying&gt;)(kSecAttrGeneric)]; [query setObject:(__bridge id)(kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly) forKey:(__bridge id&lt;NSCopying&gt;)(kSecAttrAccessible)]; [query setObject: [NSBundle mainBundle].bundleIdentifier forKey:(__bridge id&lt;NSCopying&gt;)(kSecAttrService)]; [query setObject:account forKey:(__bridge id&lt;NSCopying&gt;)(kSecAttrAccount)]; [query setObject:@YES forKey:(__bridge id&lt;NSCopying&gt;)(kSecReturnAttributes)]; [query setObject:@YES forKey:(__bridge id&lt;NSCopying&gt;)(kSecReturnData)]; CFDictionaryRef valueAttributes = NULL; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&amp;valueAttributes); NSDictionary *attributes = (__bridge_transfer NSDictionary *)valueAttributes; if(status==errSecSuccess) { NSDate_CD = [attributes objectForKey:(__bridge id)kSecAttrCreationDate]; } else { NSLog(@"Key chain query failed"); } However, some users have reported intermittent failures during app launch. Upon investigation, we discovered that these failures are caused by exceptions thrown by the iOS Keychain, which the app is currently not handling. Unfortunately, we do not log the exception or the Keychain error code in the app logs at the moment, but we plan to implement this logging feature in the near future. For now, we are trying to better understand the nature of these errors. Could you help clarify the following Keychain errors, which might be encountered from the code above? errSecServiceNotAvailable (-25307) errSecAllocate (-108) errSecNotAvailable (-25291) If these errors are encountered, are they typically persistent or are they temporary states that could resolve on their own? Your insights would be greatly appreciated. Thank you.

Hi everyone, I’m working on an iOS app that uses biometric authentication to access secure keychain items and private keys stored in the Secure Enclave with some data encryption/decryption with those keys. My goal is to minimize the number of biometric prompts by reusing the authentication result within a short time window. I have the following setup: When writing the biometry-restricted keychain items and Secure Enclave keys, I use LAContext with the property LATouchIDAuthenticationMaximumAllowableReuseDuration = 1 minute, and I pass this context as the kSecUseAuthenticationContext field in the query. When retrieving these items later (in a synchronous sequence upon app launch), I pass the same instance of LAContext as the kSecUseAuthenticationContext field. The issue: If I unlock my device and the biometric reuse time has not expired (i.e., less than 1 minute), the first two actions (keychain item retrieval and Secure Enclave key retrieval) do not prompt for Face ID. However, when I attempt to decrypt data with the private key using SecKeyCreateDecryptedData, I’m prompted for Face ID even if the biometric reuse time is still valid. If the biometric reuse time has expired (more than 1 minute since last authentication), I get prompted for Face ID on the first action (keychain retrieval), and subsequent actions (including data decryption) reuse that biometric result. Question: Does this behavior mean that SecKeyCreateDecryptedData ignore the LATouchIDAuthenticationMaximumAllowableReuseDuration property of LAContext, causing an additional biometric prompt during decryption with the private key? Or is there another reason for this behavior? Is there a way to make the biometric result reusable across all these actions, including decryption? Thank you!