Hi everyone,
I'm working on an app that stores multiple secrets in the Keychain, each protected with .userPresence.
My goal is to authenticate the user once via FaceID/TouchID and then read multiple Keychain items without triggering subsequent prompts.
I am reusing the same LAContext instance for these operations, and I have set:
context.touchIDAuthenticationAllowableReuseDuration = LATouchIDAuthenticationMaximumAllowableReuseDuration
However, I'm observing that every single SecItemCopyMatching call triggers a new FaceID/TouchID prompt, even if they happen within seconds of each other using the exact same context.
Here is a simplified flow of what I'm doing:
Create a LAContext.
Set touchIDAuthenticationAllowableReuseDuration to max.
Perform a query (SecItemCopyMatching) for Item A, passing [kSecUseAuthenticationContext: context].
Result: System prompts for FaceID. Success.
Immediately perform a query (SecItemCopyMatching) for Item B, passing the same [kSecUseAuthenticationContext: context].
Result: System prompts for FaceID again.
My question is:
Does the .userPresence access control flag inherently force a new user interaction for every Keychain access, regardless of the LAContext reuse duration? Is allowableReuseDuration only applicable for LAContext.evaluatePolicy calls and not for SecItem queries?
If so, is there a recommended pattern for "unlocking" a group of Keychain items with a single biometric prompt?
Environment: iOS 17+, Swift.
Thanks!
Prioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Hi
I am experiencing a persistent 'invalid_client' error when attempting to exchange the authorization code for an access token using Sign in with Apple for my website (https://www.vitamarinaweb.com).
Current Setup & Steps Taken:
Identifier: I am using the Service ID com.vitamarinaweb.web1, which is correctly linked to the Primary App ID com.vitamarinaweb.web.
Client Secret: I have generated a fresh Client Secret (JWT) using a valid Key (.p8) and confirmed the Team ID (29J763Q88J) and Key ID (RRW6536D27) are correct.
Redirect URIs: My Return URL is set to https://www.vitamarinaweb.com/login.php and I have verified there are no trailing spaces or mismatches.
Manual Test (CURL): When I perform a manual POST request via CURL using the generated Client Secret, I receive an 'invalid_grant' response (meaning the Client Secret and Client ID are accepted, and only the temporary code is rejected as expected).
The Issue: Despite the CURL success, every request initiated through the web browser/PHP application returns {"error":"invalid_client"}.
Verification Requested:
Could you please verify if there is a synchronization delay or a specific block on Service ID com.vitamarinaweb.web1?
Is there any internal mismatch between the Key ID RRW6536D27 and its association with the newly created Service ID?
I have already cleared browser caches and tried multiple devices (different IP addresses) with the same result.
Thank you for your assistance."
can i get transferid by /auth/usermigrationinfo api before transfered app?
https://developer.apple.com/documentation/sign_in_with_apple/transferring-your-apps-and-users-to-another-team#Generate-the-transfer-identifier
Trusted execution is a generic name for a Gatekeeper and other technologies that aim to protect users from malicious code.
General:
Forums topic: Code Signing
Forums tag: Gatekeeper
Developer > Signing Mac Software with Developer ID
Apple Platform Security support document
Safely open apps on your Mac support article
Hardened Runtime document
WWDC 2022 Session 10096 What’s new in privacy covers some important Gatekeeper changes in macOS 13 (starting at 04: 32), most notably app bundle protection
WWDC 2023 Session 10053 What’s new in privacy covers an important change in macOS 14 (starting at 17:46), namely, app container protection
WWDC 2024 Session 10123 What’s new in privacy covers an important change in macOS 15 (starting at 12:23), namely, app group container protection
Updates to runtime protection in macOS Sequoia news post
Testing a Notarised Product forums post
Resolving Trusted Execution Problems forums post
App Translocation Notes (aka Gatekeeper path randomisation) forums post
Most trusted execution problems are caused by code signing or notarisation issues. See Code Signing Resources and Notarisation Resources.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Hello,
we are using DeviceCheck – App Attest in a production iOS app. The integration has been live for some time and works correctly for most users, but a small subset of users encounter non-deterministic failures that we are unable to reproduce internally.
Environment
iOS 14+
Real devices only (no simulator)
App Attest capability enabled
Correct App ID, Team ID and App Attest entitlement
Production environment
Relevant code
let service = DCAppAttestService.shared
service.generateKey { keyId, error in
// key generation
}
service.attestKey(keyId, clientDataHash: hash) { attestation, error in
// ERROR: com.apple.devicecheck.error 3 / 4
}
service.generateAssertion(keyId, clientDataHash: clientDataHash) { assertion, error in
// ERROR: com.apple.devicecheck.error 3 / 4
}
For some users we intermittently receive:
com.apple.devicecheck.error error 3
com.apple.devicecheck.error error 4
Characteristics:
appears random
affects only some users/devices
sometimes resolves after time or reinstall
not reproducible on our test devices
NSError contains no additional diagnostic info
Some questions:
What is the official meaning of App Attest errors 3 and 4?
Are these errors related to key state, device conditions, throttling, or transient App Attest service issues?
Is there any recommended way to debug or gain more insight when this happens in production?
Any guidance would be greatly appreciated, as this impacts real users and is difficult to diagnose.
Thank you.
Hello,
I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client.
I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com).
Here is an example of the decoded payload I received:
{ "iss": "https://appleid.apple.com", "aud": "xxx", "exp": 1764402438, "iat": 1764316038, "sub": "xxxxxxxx", "c_hash": "3FAJNf4TILzUgo_YFe4E0Q", "email": "xxx@privaterelay.appleid.com", "email_verified": true, "auth_time": 1764316038, "nonce_supported": true // "is_private_email": true <-- This field is missing }
My Questions:
Is the is_private_email claim considered optional in the ID Token?
Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email?
Any insights or official references would be appreciated.
Thanks.
We implemented a feature to receive name and email address after Sign in with Apple, and it works perfectly in our testing.
However, during the app review, they says it doesn't work, and the app is rejected.
Why does it work differently?
Hello,
I am implementing "Sign in with Apple" on my backend and validating the Identity Token (JWT) received from the client.
I noticed that for some users who choose the "Hide My Email" option, the is_private_email claim is missing from the ID Token payload, even though the email address clearly belongs to the private relay domain (@privaterelay.appleid.com).
Here is an example of the decoded payload I received:
{
"iss": "https://appleid.apple.com",
"aud": "com.platform.elderberry.new.signinwithapple",
"exp": 1764402438,
"iat": 1764316038,
"sub": "000851.86193ef81ad247feb673746c19424f28.0747",
"c_hash": "3FAJNf4TILzUgo_YFe4E0Q",
"email": "x8sqp2dgvv@privaterelay.appleid.com",
"email_verified": true,
"auth_time": 1764316038,
"nonce_supported": true
// "is_private_email": true <-- This field is missing
}
My Questions:
Is the is_private_email claim considered optional in the ID Token?
Is it safe and recommended to rely solely on the email domain suffix (@privaterelay.appleid.com) to identify if a user is using a private email?
Any insights or official references would be appreciated.
Thanks.
I have a very basic binary question around passkeys.
Assuming everything is on latest and greatest version with respect to iOS, when user starts creating a passkey in platform-authenticator i.e., iCloudKeyChain (Apple Password Manager) ,
will iCloudKeyChain create a hardware-bound passkey in secure-enclave i.e., is brand new key-pair created right inside Secure-enclave ?
OR
will the keypair be created in software i.e., software-bound-passkey ?? i.e., software-bound keypair and store the private-key locally in the device encrypted with a key that is of course created in secure-enclave.
Topic:
Privacy & Security
SubTopic:
General
Tags:
Passkeys in iCloud Keychain
Authentication Services
I received a notification stating that we need to register a server-to-server notification endpoint to handle the following three events:
Changes in email forwarding preferences.
Account deletions in your app.
Permanent Apple Account deletions.
However, even though we have registered the API endpoint under our Identifier configuration, it appears that we are not receiving any API calls when these events trigger.
I honestly have no idea what’s going wrong. I’ve checked our WAF logs and there’s no trace of any incoming traffic at all. Is it possible that Apple hasn't started sending
these notifications yet, or is there something I might be missing? I’m stuck and don’t know how to resolve this. I would really appreciate any help or insights you could share.
Thank you.
Topic:
Privacy & Security
SubTopic:
Sign in with Apple
Hello,
We are working on integrating app integrity verification into our service application, following Apple's App Attest and DeviceCheck guide.
Our server issues a challenge to the client, which then sends the challenge, attestation, and keyId in CBOR format to Apple's App Attest server for verification. However, we are unable to reach both https://attest.apple.com and https://attest.development.apple.com due to network issues.
These attempts have been made from both our internal corporate network and mobile hotspot environments. Despite adjusting DNS settings and other configurations, the issue persists.
Are there alternative methods or solutions to address this problem? Any recommended network configurations or guidelines to successfully connect to Apple's App Attest servers would be greatly appreciated.
Thank you.
冷启动后我们读文件,发现:"error_msg":"未能打开文件“FinishTasks.plist”,因为你没有查看它的权限。
是否有这些问题:
「iOS 26 iPhone 16,2 cold launch file access failure」)
核心内容:多名开发者反馈 iPhone 15 Pro(iOS 26.0/26.1)冷启动时读取 Documents 目录下的 plist 文件提示权限拒绝,切后台再切前台恢复,苹果员工回复「建议延迟文件操作至 applicationDidBecomeActive 后」。
Topic:
Privacy & Security
SubTopic:
General
Feedback report id: FB16605524
I'm trying to send emails to private relay service addresses using AWS SES and emails are not received. My emails are sent from dev@mydomain.fr and I've set a custom FROM domain of mail.mydomain.fr. I've added both domains and the dev@mydomain.fr adress to the "Certificates, Identifies & Profiles" section. I've set up DKIM and SPF for both.
Attached a redacted version of email headers.
email_headers_redacted.txt
Hi,
We are operating a service that uses Sign in with Apple for user registration and login.
As part of our security incident response and periodic security improvements, we are planning to rotate the private key used to generate the client secret (JWT) for Sign in with Apple.
I have read the Human Interface Guidelines and the AuthenticationServices documentation, but I could not find a clear description of the behavior and user impact when rotating this private key. I would like to ask the following questions:
Background:
We issue a Sign in with Apple private key (with a Key ID) in our Apple Developer account.
Our server uses this private key to generate the client secret (JWT).
This is used for Sign in with Apple login on our web / mobile app.
We are planning to invalidate the existing private key and switch to a newly issued one.
Questions:
Impact on existing logged-in sessions
Will rotating the private key force already logged-in users (who previously signed in with Apple) to be logged out from our service?
Can the user identifier (such as the "sub" claim) for existing Sign in with Apple users change due to key rotation?
Recommended frequency and best practices
Does Apple recommend rotating this private key only when it is compromised, or on a regular basis?
If there are any official documents or examples that describe how to safely perform key rotation in production, we would appreciate a pointer.
Impact on marketing / analytics
We are using user IDs (linked via Sign in with Apple) for analytics and marketing attribution.
Is there any expected impact on such use cases caused by rotating the private key?
For example, is there any possibility that user identifiers change as a result of key rotation, or anything we should be careful about from a data linkage perspective?
Our goal is to rotate the private key in a secure way without causing service downtime, mass logouts, or loss of account linkage.
If there is already an official document that covers this, please let me know the URL.
Thank you in advance.
Dear Apple Developer Support Team,
We are experiencing a recurring issue with the DeviceCheck API where the following error is being returned:
com.apple.devicecheck.error 0
Upon analyzing our logs, we have noticed that this error occurs significantly more often when users are connected to Wi-Fi networks, compared to mobile networks. This leads us to suspect that there might be a relationship between Wi-Fi configuration and the DeviceCheck service’s ability to generate or validate tokens.
We would like to know:
Is this error code (0) known to be caused by specific types of network behavior or misconfigurations on Wi-Fi networks (e.g., DNS filtering, firewall restrictions, proxy servers)?
Are there any recommended best practices for ensuring reliable DeviceCheck API communication over Wi-Fi networks?
Additionally, could you please clarify what general conditions could trigger this com.apple.devicecheck.error 0? The lack of specific documentation makes debugging this issue difficult from our side.
Any guidance or internal documentation on this error code and its potential causes would be greatly appreciated.
IDE: Xcode 16.3
Looking forward to your support.
Best regards,
From watching the video on App Attest the answer would appear to be no, but the video is a few years old so in hope, I thought I would post this question anyway.
There's several scenarios where I would like a notification service extension to be able to use App Attest in communications with the back end(for example to send a receipt to the backend acknowledging receipt of the push, fetching an image from a url in the push payload, a few others).
Any change App Attest can be used in by a notification service extension?
Hello,
When using ASWebAuthenticationSession with an HTTPS callback URL (Universal Link), I receive the following error:
Authorization error: The operation couldn't be completed.
Application with identifier jp.xxxx.yyyy.dev is not associated with domain xxxx-example.go.link.
Using HTTPS callbacks requires Associated Domains using the webcredentials service type for xxxx-example.go.link.
I checked Apple’s official documentation but couldn’t find any clear statement that webcredentials is required when using HTTPS callbacks in ASWebAuthenticationSession.
What I’d like to confirm:
Is webcredentials officially required when using HTTPS as a callback URL with ASWebAuthenticationSession?
If so, is there any official documentation or technical note that states this requirement?
Environment
iOS 18.6.2
Xcode 16.4
Any clarification or official references would be greatly appreciated.
Thank you.
Topic:
Privacy & Security
SubTopic:
General
Tags:
iOS
Security
Authentication Services
Universal Links
Recently, we have adapted the passkey function on the Mac, but we always encounter the error message "Unable to verify the web credentials association of xxx with domain aaa. Please try again in a few seconds."
We can confirm that https://aaa/.well-known/apple-app-site-association has been configured and is accessible over the public network. Additionally, the entitlements in the app have also been set with webcredentials:aaa.
This feature has been experiencing inconsistent performance. When I restart my computer or reinstall the pkg, this feature may work or it may still not work. I believe this is a system issue.
Here is feed back ID: FB20876945
In the feedback, I provided the relevant logs.
If you have any suggestions or assistance, please contact me. I would be extremely grateful!
Topic:
Privacy & Security
SubTopic:
General
Tags:
macOS
Objective-C
Authentication Services
Passkeys in iCloud Keychain
Hello, I'm receiving an unknown error instead of the excluded credentials error when using the "Save on another device" option for Passkey creation.
When creating the ASAuthorizationPlatformPublicKeyCredentialProvider request to pass to the ASAuthorizationController. The excludedCredentials property is used to add a list of credentials to exclude in the registration process. This is to prevent duplicate passkeys from being created if one already exists for the user.
When trying to create a duplicate passkey using the same device, the ASAuthorizationControllerDelegate method authorizationController(controller, didCompleteWithError:) is called. The error received has localized description “At least one credential matches an entry of the excludeCredentials list in the platform attached authenticator."
When trying to create a duplicate passkey using the “Save on another device” option. The delegate method is called, but the error received has code 1000 ("com.apple.AuthenticationServices.AuthorizationError" - code: 1000). Which maps to the unknown error case in ASAuthorization error type.
Topic:
Privacy & Security
SubTopic:
General
Tags:
Passkeys in iCloud Keychain
Authentication Services
I'm experiencing a strange issue where ASWebAuthenticationSession works perfectly when running from Xcode (both Debug and Release), but fails on TestFlight builds.
The setup:
iOS app using ASWebAuthenticationSession for OIDC login (Keycloak)
Custom URL scheme callback (myapp://)
prefersEphemeralWebBrowserSession = false
The issue:
When using iOS Keychain autofill (with Face ID/Touch ID or normal iphone pw, that auto-submits the form) -> works perfectly
When manually typing credentials and clicking the login button -> fails with white screen
When it fails, the form POST from Keycloak back to my server (/signin-oidc) never reaches the server at all. The authentication session just shows a white screen.
Reproduced on:
Multiple devices (iPhone 15 Pro, etc.)
iOS 18.x
Xcode 16.x
Multiple TestFlight testers confirmed same behavior
What I've tried:
Clearing Safari cookies/data
prefersEphemeralWebBrowserSession = true and false
Different SameSite cookie policies on server
Verified custom URL scheme is registered and works (testing myapp://test in Safari opens the app)
Why custom URL scheme instead of Universal Links:
We couldn't get Universal Links to trigger from a js redirect (window.location.href) within ASWebAuthenticationSession. Only custom URL schemes seemed to be intercepted. If there's a way to make Universal Links work in this context, without a manual user-interaction we'd be happy to try.
iOS Keychain autofill works
The only working path is iOS Keychain autofill that requires iphone-authentication and auto-submits the form. Any manual form submission fails, but only on TestFlight - not Xcode builds.
Has anyone encountered this or know a workaround?