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.
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, we were recently approved for the com.apple.developer.web-browser.public-key-credential entitlement and have added it to our app. It initially worked as expected for a couple of days, but then it stopped working. We're now seeing the same error as before adding the entitlement:
Told not to present authorization sheet: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 "(null)"
ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)"
Do you have any insights into what might be causing this issue?
Thank you!
I now had the second user with 26.2. complaining about a hang in my app. The hang occurs when the first AppleScript for Mail is run. Here is the relevant section from the process analysis in Activity Monitor:
+ 2443 OSACompile (in OpenScripting) + 52 [0x1b32b30f4]
+ 2443 SecurityPolicyTestDescriptor (in OpenScripting) + 152 [0x1b32a2284]
+ 2443 _SecurityPolicyTest(char const*, void const*, unsigned long) (in OpenScripting) + 332 [0x1b32a2118]
+ 2443 InterpreterSecurity_ScanBuffer (in libInterpreterSecurity.dylib) + 112 [0x28c149304]
+ 2443 -[InterpreterSecurity scanData:withSourceURL:] (in libInterpreterSecurity.dylib) + 164 [0x28c148db4]
+ 2443 -[XProtectScan beginAnalysisWithFeedback:] (in XprotectFramework) + 544 [0x1d35a1e58]
+ 2443 -[XPMalwareEvaluation initWithData:assessmentClass:] (in XprotectFramework) + 92 [0x1d359ada4]
+ 2443 -[XPMalwareEvaluation initWithRuleString:withExtraRules:withURL:withData:withAssessmentClass:feedback:] (in XprotectFramework) + 36 [0x1d359b2a8]
My app is correctly signed and notarised. The first user had to completely uninstall/reinstall the app and the everything worked again.
Why does this happen? How can the problem be fixed?
I'm trying to export and re-import a P-256 private key that was originally generated via SecKeyCreateRandomKey(), but I keep running into roadblocks. The key is simply exported via SecItemExport() with format formatWrappedPKCS8, and I did set a password just to be sure.
Do note that I must use the file-based keychain, as the data protection keychain requires a restricted entitlement and I'm not going to pay a yearly fee just to securely store some private keys for a personal project. The 7-day limit for unsigned/self-signed binaries isn't feasible either.
Here's pretty much everything I could think of trying:
Simply using SecItemImport() does import the key, but I cannot set kSecAttrLabel and more importantly: kSecAttrApplicationTag. There just isn't any way to pass these attributes upfront, so it's always imported as Imported Private Key with an empty comment. Keys don't support many attributes to begin with and I need something that's unique to my program but shared across all the relevant key entries, otherwise it's impossible to query for only my program's keys. kSecAttrLabel is already used for something else and is always unique, which really only leaves kSecAttrApplicationTag. I've already accepted that this can be changed via Keychain Access, as this attribute should end up as the entry's comment. At least, that's how it works with SecKeyCreateRandomKey() and SecItemCopyMatching(). I'm trying to get that same behaviour for imports.
Running SecItemUpdate() afterwards to set these 2 attributes doesn't work either, as now the kSecAttrApplicationTag is suddenly used for the entry's label instead of the comment. Even setting kSecAttrComment (just to be certain) doesn't change the comment. I think kSecAttrApplicationTag might be a creation-time attribute only, and since SecItemImport() already created a SecKey I will never be able to set this. It likely falls back to updating the label because it needs to target something that is still mutable?
Using SecItemImport() with a nil keychain (i.e. create a transient key), then persisting that with SecItemAdd() via kSecValueRef does allow me to set the 2 attributes, but now the ACL is lost. Or more precise: the ACL does seem to exist as any OS prompts do show the label I originally set for the ACL, but in Keychain Access it shows as Allow all applications to access this item. I'm looking to enable Confirm before allowing access and add my own program to the Always allow access by these applications list. Private keys outright being open to all programs is of course not acceptable, and I can indeed access them from other programs without any prompts.
Changing the ACL via SecKeychainItemSetAccess() after SecItemAdd() doesn't seem to do anything. It apparently succeeds but nothing changes. I also reopened Keychain Access to make sure it's not a UI "caching" issue.
Creating a transient key first, then getting the raw key via SecKeyCopyExternalRepresentation() and passing that to SecItemAdd() via kSecValueData results in The specified attribute does not exist. This error only disappears if I remove almost all of the attributes. I can pass only kSecValueData, kSecClass and kSecAttrApplicationTag, but then I get The specified item already exists in the keychain errors. I found a doc that explains what determines uniqueness, so here are the rest of the attributes I'm using for SecItemAdd():
kSecClass: not mentioned as part of the primary key but still required, otherwise you'll get One or more parameters passed to a function were not valid.
kSecAttrLabel: needed for my use case and not part of the primary key either, but as I said this results in The specified attribute does not exist.
kSecAttrApplicationLabel: The specified attribute does not exist. As I understand it this should be the SHA1 hash of the public key, passed as Data. Just omitting it would certainly be an option if the other attributes actually worked, but right now I'm passing it to try and construct a truly unique primary key.
kSecAttrApplicationTag: The specified item already exists in the keychain.
kSecAttrKeySizeInBits: The specified attribute does not exist.
kSecAttrEffectiveKeySize: The specified attribute does not exist.
kSecAttrKeyClass: The specified attribute does not exist.
kSecAttrKeyType: The specified attribute does not exist.
It looks like only kSecAttrApplicationTag is accepted, but still ignored for the primary key. Even entering something that is guaranteed to be unique still results in The specified item already exists in the keychain, so I think might actually be targeting literally any key. I decided to create a completely new keychain and import it there (which does succeed), but the key is completely broken. There's no Kind and Usage at the top of Keychain Access and the table view just below it shows symmetric key instead of private. The kSecAttrApplicationTag I'm passing is still being used as the label instead of the comment and there's no ACL. I can't even delete this key because Keychain Access complains that A missing value was detected. It seems like the key doesn't really contain anything unique for its primary key, so it will always match any existing key.
Using SecKeyCreateWithData() and then using that key as the kSecValueRef for SecItemAdd() results in A required entitlement isn't present. I also have to add kSecUseDataProtectionKeychain: false to SecItemAdd() (even though that should already be the default) but then I get The specified item is no longer valid. It may have been deleted from the keychain. This occurs even if I decrypt the PKCS8 manually instead of via SecItemImport(), so it's at least not like it's detecting the transient key somehow. No combination of kSecAttrIsPermanent, kSecUseDataProtectionKeychain and kSecUseKeychain on either SecKeyCreateWithData() or SecItemAdd() changes anything.
I also tried PKCS12 despite that it always expects an "identity" (key + cert), while I only have (and need) a private key. Exporting as formatPKCS12 and importing it with itemTypeAggregate (or itemTypeUnknown) does import the key, and now it's only missing the kSecAttrApplicationTag as the original label is automatically included in the PKCS12. The outItems parameter contains an empty list though, which sort of makes sense because I'm not importing a full "identity". I can at least target the key by kSecAttrLabel for SecItemUpdate(), but any attempt to update the comment once again changes the label so it's not really any better than before.
SecPKCS12Import() doesn't even import anything at all, even though it does return errSecSuccess while also passing kSecImportExportKeychain explicitly.
Is there literally no way?
During internal testing, we observed the following behavior and would appreciate clarification on whether it is expected and supported in production environments.
When generating an elliptic-curve cryptographic key pair using "kSecAttrTokenIDSecureEnclave", and explicitly specifying a "kSecAttrAccessGroup", we found that cryptographic operations (specifically encryption and decryption) could be successfully performed using this key pair from two distinct applications. Both applications had the Keychain Sharing capability enabled and were signed with the same provisioning profile identity.
Given the documented security properties of Secure Enclave, backed keys, namely that private key material is protected by hardware and access is strictly constrained by design, we would like to confirm whether the ability for multiple applications (sharing the same keychain access group and signing identity) to perform cryptographic operations with the same Secure Enclave–backed key is expected behavior on iOS.
Specifically, we are seeking confirmation on:
Whether this behavior is intentional and supported in production.
Whether the Secure Enclave enforces access control primarily at the application-identifier (App ID) level rather than the individual app bundle level in this scenario.
Whether there are any documented limitations or guarantees regarding cross-application usage of Secure Enclave keys when keychain sharing is configured.
Any guidance or references to official documentation clarifying this behavior would be greatly appreciated.
Topic:
Privacy & Security
SubTopic:
General
Hi everyone,
I am currently implementing Server-to-Server Notifications for Sign in with Apple. I’ve encountered a discrepancy between the official documentation and the actual payload I received, and I would like to clarify which one is correct.
The Situation: I triggered an account deletion event via privacy.apple.com to test the notification flow. When my server received the notification, the type field in the JSON payload was account-deleted (past tense).
The Issue: According to the official Apple documentation, the event type is listed as account-delete (present tense).
Here is the discrepancy I am observing:
Documentation: account-delete
Actual Payload: account-deleted
My Question: Is the documentation outdated, or is this a known inconsistency? Should I handle both strings (account-delete and account-deleted) in my backend logic to be safe, or is account-deleted the new standard?
Any insights or confirmation from those who have implemented this would be greatly appreciated.
Thanks!
I've made my first app and encountered an unexpected (potentially existential) issue.
The Manager app is designed to tag 3rd party "plugins" used by a DAW, storing metadata in a local SQLite database, and move them between Active and Inactive folders. This allows management of the plugin collection - the DAW only uses what's in the Active folder.
Permissions are obtained via security-scoped bookmarks on first launch. The app functions as intended: plugin bundles move correctly and the database tracks everything. No information is written to the plugins themselves.
The Problem:
When moving plugins using fs.rename() , the MAS sandbox automatically adds the com.apple.quarantine extended attribute to moved files. When the DAW subsequently rebuilds its plugin cache, it interprets quarantined plugins as "corrupt" or potentially malicious and refuses to load them.
Technical Details:
Moving files with NSFileManager or Node.js fs APIs within sandbox triggers quarantine
Sandboxed apps cannot call xattr -d com.apple.quarantine or use removexattr()
The entitlement com.apple.security.files.user-selected.read-write doesn't grant xattr removal rights
User workaround: run xattr -cr /path/to/plugins in Terminal - not acceptable for professional users
Question:
Is there any MAS-compliant way to move files without triggering quarantine, or to remove the quarantine attribute within the sandbox? The hardened-runtime DMG build works perfectly (no sandbox = no quarantine added).
Any insight appreciated!
Hi,
I am in need of your help with publishing my game.
I got the following explanation for the negative review of my app/game.
Issue Description
One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used.
Next Steps
Update the local network information purpose string to explain how the app will use the requested information and provide a specific example of how the data will be used. See the attached screenshot.
Resources
Purpose strings must clearly describe how an app uses the ability, data, or resource. The following are hypothetical examples of unclear purpose strings that would not pass review:
"App would like to access your Contacts"
"App needs microphone access"
See examples of helpful, informative purpose strings.
The problem is that they say my app asks to allow my app to find devices on local networks. And that this needs more explanation in the purpose strings.
Totally valid to ask, but the problem is my app doesn't need local access to devices, and there shouldn't be code that asks this?? FYI the game is build with Unity.
Would love some help on how to turn this off so that my app can get published.
Hi,
I have an application that uses SecureEnclave keys to protect secrets. By passing an LAContext object to the Secure Enclave operations, authentication state can be preserved across decrypt operations, and you do not need to re-authenticate for doing different operations.
However, for security reasons, I would like to avoid that it is possible to do operations in batch with certain keys generated by the Secure Enclave, by any application. This would avoid malicious binaries to batch-extract all the secrets that are protected by a key from my Secure Enclave, and force to re-authenticate on every operation.
Is there a way to prevent batch operations without re-authenticating for Secure Enclave keys?
thanks,
Remko
We recently upgraded OpenSSL from version 1.1.1 to 3.4.0. After this upgrade, we observed that PKCS#12 files generated using OpenSSL 3.4.0 fail to import into the macOS Keychain with the following error:
Failed to import PKCS#12 data: -25264
(MAC verification failed during PKCS12 import (wrong password?))
This issue is reproducible on macOS 14.8.2. The same PKCS#12 files import successfully on other macOS versions, including 15.x and 26.x.
Additionally, PKCS#12 files that fail to import on macOS 14.8 work correctly when copied and imported on other macOS versions without any errors.
PKCS#12 Creation
The PKCS#12 data is created using the following OpenSSL API:
const char* platformPKCS12SecureKey =
_platformSecureKey.has_value() ? _platformSecureKey.value().c_str() : NULL;
PKCS12* p12 = PKCS12_create(
platformPKCS12SecureKey,
NULL,
keys,
_cert,
NULL,
0, 0, 0, 0, 0
);
if (!p12)
{
throw std::runtime_error("Failed to create PKCS#12 container");
}
PKCS#12 Import
The generated PKCS#12 data is imported into the macOS Keychain using the following code:
NSString *certPassKey = [NSString stringWithUTF8String:getCertPassKey()];
NSDictionary *options = @{
(__bridge id)kSecImportExportPassphrase: certPassKey,
(__bridge id)kSecAttrAccessible:
(__bridge id)kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly,
(__bridge id)kSecAttrIsExtractable: @YES,
(__bridge id)kSecAttrIsPermanent: @YES,
(__bridge id)kSecAttrAccessGroup: APP_GROUP
};
CFArrayRef items = NULL;
OSStatus status = SecPKCS12Import(
(__bridge CFDataRef)pkcs12Data,
(__bridge CFDictionaryRef)options,
&items
);
Topic:
Privacy & Security
SubTopic:
General
Tags:
macOS
Signing Certificates
iCloud Keychain Verification Codes
Passkeys in iCloud Keychain
Hi Apple Developers,
I'm having a problem with evaluatedPolicyDomainState: on the same device, its value keeps changing and then switching back to the original. My current iOS version is 26.1.
I upgraded my iOS from version 18.6.2 to 26.1.
What could be the potential reasons for this issue?
{
NSError *error;
BOOL success = YES;
char *eds = nil;
int edslen = 0;
LAContext *context = [[LAContext alloc] init];
// test if we can evaluate the policy, this test will tell us if Touch ID is available and enrolled
// success = [context canEvaluatePolicy: LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error];
if (SystemVersion > 9.3) {
// test if we can evaluate the policy, this test will tell us if Touch ID is available and enrolled
success = [context canEvaluatePolicy: LAPolicyDeviceOwnerAuthentication error:&error];
}
else{
// test if we can evaluate the policy, this test will tell us if Touch ID is available and enrolled
success = [context canEvaluatePolicy: LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error];
}
if (success)
{
if (@available(iOS 18.0, *)) {
NSData *stateHash = nil;
if ([context respondsToSelector:@selector(domainState)]) {
stateHash = [[context performSelector:@selector(domainState)] performSelector:@selector(stateHash)];
}else{
stateHash = [context evaluatedPolicyDomainState];
}
eds = (char *)stateHash.bytes;
edslen = (int)stateHash.length;
} else {
eds = (char *)[[context evaluatedPolicyDomainState] bytes];
edslen = (int)[[context evaluatedPolicyDomainState] length];
}
CC_SHA256(eds, edslen, uviOut);
*poutlen = CC_SHA256_DIGEST_LENGTH;
}
else
{
*poutlen = 32;
gm_memset(uviOut, 0x01, 32);
}
}
Is there any way for an iOS app to get a log of all Airdrop transfers originating in all apps on the iOS device e.g. from the last week?
Topic:
Privacy & Security
SubTopic:
General
Hello,
I am developing a macOS menu bar window-management utility (similar in functionality to Magnet / Rectangle) that relies on the Accessibility (AXUIElement) API to move and resize windows and on global hotkeys.
I am facing a consistent issue when App Sandbox is enabled.
Summary:
App Sandbox enabled
Hardened Runtime enabled
Apple Events entitlement enabled
NSAccessibilityDescription present in Info.plist
AXIsProcessTrustedWithOptions is called with prompt enabled
Observed behavior:
When App Sandbox is enabled, the Accessibility permission prompt never appears.
The app cannot be manually added in System Settings → Privacy & Security → Accessibility.
AXIsProcessTrusted always returns false.
As a result, window snapping does not work.
When App Sandbox is disabled:
The Accessibility prompt appears correctly.
The app functions as expected.
This behavior occurs both:
In local builds
In TestFlight builds
My questions:
Is this expected behavior for sandboxed macOS apps that rely on Accessibility APIs?
Are window-management utilities expected to ship without App Sandbox enabled?
Is there any supported entitlement or configuration that allows a sandboxed app to request Accessibility permission?
Thank you for any clarification.
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
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
On macOS 26.1 (25B78) I can't give Full Disk Access to sshd-keygen-wrapper. Now my Jenkins jobs do not work because they do not have the permission to execute the necessary scripts. Until macOS 26.1 everything worked fine. I restarted the machine several times and tried to give access from Settings -> Privacy & Security -> Full Disk Access but it just does not work. I tried logging with ssh on the machine and executing a script but again nothing happened.
I can't find any information about why this is happening, nor can I reproduce the 'successful' state on this device. My team needs to understand this behavior, so any insight would be greatly appreciated!
The expected behavior: If I delete both apps and reinstall them, attempting to open the second app from my app should trigger the system confirmation dialog.
The specifics: I'm using the MSAL library. It navigates the user to the Microsoft Authenticator app and then returns to my app. However, even after resetting the phone and reinstalling both apps, the dialog never shows up (it just opens the app directly).
Does anyone know the logic behind how iOS handles these prompts or why it might be persistent even after a reset?
Thanks in advance!
Topic:
Privacy & Security
SubTopic:
General
I'm implementing Apple Sign-In in my Next.js application with a NestJS backend. After the user authenticates with Apple, instead of redirecting to my configured callback URL, the browser makes a POST request to a mysterious endpoint /appleauth/auth/federate that doesn't exist in my codebase, resulting in a 404 error.
Tech Stack
Frontend: Next.js 16.0.10, React 19.2.0
Backend: NestJS with Passport (using @arendajaelu/nestjs-passport-apple)
Frontend URL: https://myapp.example.com
Backend URL: https://api.example.com
Apple Developer Configuration
Service ID: (configured correctly in Apple Developer Console)
Return URL (only one configured):
https://api.example.com/api/v1/auth/apple/callback
Domains verified in Apple Developer Console:
myapp.example.com
api.example.com
example.com
Backend Configuration
NestJS Controller (auth.controller.ts):
typescript
@Public()
@Get('apple')
@UseGuards(AuthGuard('apple'))
async appleAuth() {
// Initiates Apple OAuth flow
}
@Public()
@Post('apple/callback') // Changed from @Get to @Post for form_post
@UseGuards(AuthGuard('apple'))
async appleAuthCallback(@Req() req: any, @Res() res: any) {
const result = await this.authService.socialLogin(req.user, ipAddress, userAgent);
// Returns HTML with tokens that uses postMessage to send to opener window
}
Environment Variables:
typescript
APPLE_CLIENT_ID=<service_id>
APPLE_TEAM_ID=<team_id>
APPLE_KEY_ID=<key_id>
APPLE_PRIVATE_KEY_PATH=./certs/AuthKey_XXX.p8
APPLE_CALLBACK_URL=https://api.example.com/api/v1/auth/apple/callback
FRONTEND_URL=https://myapp.example.com
The passport-apple strategy uses response_mode: 'form_post', so Apple POSTs the authorization response to the callback URL.
Frontend Implementation
Next.js API Route (/src/app/api/auth/apple/route.js):
javascript
export async function GET(request) {
const backendUrl = new URL(`${API_URL}/auth/apple`);
const response = await fetch(backendUrl.toString(), {
method: "GET",
headers: {
"Content-Type": "application/json",
},
});
const responseText = await response.text();
return new NextResponse(responseText, {
status: response.status,
headers: { "Content-Type": contentType || "text/html" },
});
}
Frontend Auth Handler:
javascript
export const handleAppleLogin = (router, setApiError) => {
const frontendUrl = window?.location?.origin;
// Opens popup to /api/auth/apple
window.open(
`${frontendUrl}/api/auth/apple`,
"appleLogin",
"width=500,height=600"
);
};
The Problem
Expected Flow:
User clicks "Login with Apple"
Frontend opens popup → https://myapp.example.com/api/auth/apple
Frontend proxies to → https://api.example.com/api/v1/auth/apple
Backend redirects to Apple's authentication page
User authenticates with Apple ID
Apple POSTs back to → https://api.example.com/api/v1/auth/apple/callback
Backend processes and returns success HTML
Actual Behavior:
After step 5 (user authentication with Apple), instead of Apple redirecting to my callback URL, the browser makes this unexpected request:
POST https://myapp.example.com/appleauth/auth/federate?isRememberMeEnabled=false
Status: 404 Not Found
Request Payload:
json
{
"accountName": "user@example.com",
"rememberMe": false
}
Network Tab Analysis
From Chrome DevTools, the call stack shows:
send @ app.js:234
ajax @ app.js:234
(anonymous) @ app.js:10
Ee.isFederated @ app.js:666
_callAuthFederate @ app.js:666
The Ee.isFederated and _callAuthFederate functions appear to be minified library code, but I cannot identify which library.
What I've Verified
✅ The /appleauth/auth/federate endpoint does not exist anywhere in my codebase:
bash
grep -r "appleauth" src/ # No results
grep -r "federate" src/ # No results
✅ Apple Developer Console shows only ONE Return URL configured (verified multiple times)
✅ Changed callback route from @Get to @Post to handle form_post response mode
✅ Rebuilt frontend completely multiple times:
bash
rm -rf .next
npm run build
✅ Tested in:
Incognito/Private browsing mode
Different browsers (Chrome, Firefox, Safari)
Different devices
After clearing all cache and cookies
✅ No service workers registered in the application
✅ No external <script> tags or CDN libraries loaded
✅ package.json contains no AWS Amplify, Auth0, Cognito, or similar federated auth libraries
✅ Checked layout.js and all root-level files - no external scripts
Additional Context
Google Sign-In works perfectly fine using the same approach
The mysterious endpoint uses a different path structure (/appleauth/ vs /api/auth/)
The call appears to originate from client-side JavaScript (based on the call stack)
The app.js file with the mysterious functions is the built Next.js bundle
Questions
Where could this /appleauth/auth/federate endpoint be coming from?
Why is the browser making this POST request instead of following Apple's redirect to my configured callback URL?
Could this be related to the response_mode: 'form_post' in the Apple Passport strategy?
Is there something in the Apple Developer Primary App ID configuration that could trigger this behavior?
Could this be a Next.js build artifact or some hidden dependency?
The mysterious call stack references (Ee.isFederated, _callAuthFederate) suggest some library is intercepting the Apple authentication flow, but I cannot identify what library or where it's being loaded from. The minified function names suggest federated authentication, but I have no such libraries in my dependencies.
Has anyone encountered similar issues with Apple Sign-In where an unexpected endpoint is being called?
Topic:
Privacy & Security
SubTopic:
Sign in with Apple
Tags:
Sign in with Apple REST API
Sign in with Apple
Hello everyone.
Hope this one finds you well)
I have an issue with integrating a FIDO2 server with ASAuthorizationController.
I have managed to register a user with passkey successfully, however when authenticating, the request for authentication response fails. The server can't validate signature field.
I can see 2 possible causes for the issue: ASAuthorizationPlatformPublicKeyCredentialAssertion.rawAuthenticatorData contains invalid algorithm information (the server tries ES256, which ultimately fails with false response), or I have messed up Base64URL encoding for the signature property (which is unlikely, since all other fields also require Base64URL, and the server consumes them with no issues).
So the question is, what encryption algorithm does ASAuthorizationController use? Maybe someone has other ideas regarding where to look into?
Please help. Thanks)
冷启动后我们读文件,发现:"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