Migrating APP and users, obtaining the user's transfer_sub, an exception occurred: {"error":"invalid_request"} `POST /auth/usermigrationinfo HTTP/1.1 Host: appleid.apple.com Content-Type: application/x-www-form-urlencoded Authorization: Bearer {access_token} sub={sub}&target={recipient_team_id}&client_id={client_id}&client_secret={client_secret} The specific request is as follows: 15:56:20.858 AppleService - --> POST https://appleid.apple.com/auth/usermigrationinfo 15:56:20.858 AppleService - Content-Type: application/x-www-form-urlencoded 15:56:20.858 AppleService - Content-Length: 395 15:56:20.858 AppleService - Authorization: Bearer a56a8828048af48c0871e73b55d8910aa.0.rzvs.96uUcy1KBqo34Kj8qrPb4w 15:56:20.858 AppleService - 15:56:20.858 AppleService - sub=001315.1535dbadc15b472987acdf634719a06a.0600&target=WLN67KBBV8&client_id=com.hawatalk.live&client_secret=eyJraWQiOiIzODg5U1ZXNDM5IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJRMzlUU1BHMjk3IiwiaWF0IjoxNzU1MDcxNzc5LCJleHAiOjE3NTUwNzUzNzksImF1ZCI6Imh0dHBzOi8vYXBwbGVpZC5hcHBsZS5jb20iLCJzdWIiOiJjb20uaGF3YXRhbGsubGl2ZSJ9.8i9RYIcepuIiEqOMu1OOAlmmjnB84AJueel21gNapiNa9pr3498Zkj8J5MUIzvvnvsvUJkKQjp_VvnsG_IIrTA 15:56:20.859 AppleService - --> END POST (395-byte body) 15:56:21.675 AppleService - <-- 400 Bad Request https://appleid.apple.com/auth/usermigrationinfo(816ms) 15:56:21.675 AppleService - Server: Apple 15:56:21.675 AppleService - Date: Wed, 13 Aug 2025 07:56:22 GMT 15:56:21.675 AppleService - Content-Type: application/json;charset=UTF-8 15:56:21.675 AppleService - Content-Length: 27 15:56:21.675 AppleService - Connection: keep-alive 15:56:21.675 AppleService - Pragma: no-cache 15:56:21.675 AppleService - Cache-Control: no-store 15:56:21.676 AppleService - 15:56:21.676 AppleService - {"error":"invalid_request"} 15:56:21.676 AppleService - <-- END HTTP (27-byte body) ` Current Team ID: Q39TSPG297 Recipient Team ID: WLN67KBBV8 CLIENT_ID: com.hawatalk.live

I have an Autofill Passkey Provider working for Safari and Chrome via WebAuthn protocol. Unfortunately, Chrome will not offer my extension as a logon credential provider unless I add the credential to the ASCredentialIdentityStore. I wonder what is the best way to access the ASCredentialIdentityStore from an AutoFill extension? I understand I cannot access it directly from the extension context, so what is the best way to trigger my container app to run, based on a new WebAuthn registration? The best I can think of so far is for the www site to provide an App Link to launch my container app as part of the registration ceremony. Safari will offer my extension even without adding it to the ASCredentialIdentityStore, so I guess I should file a request with Chrome to work this way too, given difficulty of syncing ASCredentialIdentityStore with WebAuthn registration.

We are implementing authentication login in our iOS mobile application, and during the sign-in/sign-out process, a native system popup appears with the following message: "This allows the app and website to share information about you." This popup interrupts the user experience, and we are concerned it may cause confusion for end users and negatively impact the adoption of our login flow. We would like clarification on the following points: What triggers this popup during the authentication process? Are there any recommended configurations or approaches to suppress or avoid this dialog? If the popup cannot be avoided, what best practices are suggested to ensure a clear and seamless user experience? Our objective is to provide a smooth, user-friendly authentication flow without unexpected system interruptions.

I'm building a macOS app that registers itself for HTTP(S) url handling and would like it to participate in the ASWebAuthenticationSession fow. I did: update the plist to register as a handler for URL shemes (http, https, file) use NSWorkspace setDefaultApplication API to set this app as a default handler for urls in question wrote custom ASWebAuthenticationSessionWebBrowserSessionHandling implementation and set it as SessionManager's sessionHandler I launched this app from Xcode, then I triggered authentication flow from a third-party app. When the sign in flow is initiated, I can see that my app is activeated (willBecomeActive and didBecomeActive callbacks are both called), but there is no call for sessionHandler's begin() method. With some additional debugging I see that my app receives an apple event when the flow is started: {sfri,auth target=SafariLaunchAgent {qntp=90/$627......},aapd=TRUE If I switch system default browser back to Safari and then start the login flow, it correctly displays a sign in web page. What do I miss? PS. I'm on Tahoe 26.2

https://aninterestingwebsite.com/documentation/apptrackingtransparency/attrackingmanager/authorizationstatus/notdetermined Note: Discussion If you call ATTrackingManager.trackingAuthorizationStatus in macOS, the result is always ATTrackingManager.AuthorizationStatus.notDetermined. So, does macOS support getting ATT?

Hello, I have a question regarding the lifecycle of user consent and tokens in "Sign in with Apple." Specifically, I would like to understand the behavior of the auth/revoke API in relation to App Store Connect status changes. Impact of App Status Changes If an app is "Removed from Sale" or "Deleted" from App Store Connect, does Apple automatically revoke all associated user tokens and consent? Or is it still the developer's responsibility to programmatically revoke each user's token via the REST API to ensure the app is removed from the user’s "Apps Using Apple ID" list? API Availability after Removal Once an app is no longer available on the App Store (or its record is deleted in App Store Connect), is the auth/revoke REST API still accessible? I want to ensure that a developer can still perform necessary privacy clean-up tasks (revoking consent) even if the app is not currently distributed. Specific User Impacts of Non-Revocation If we do not call the revocation API, besides the app remaining in the "Sign in with Apple" list, what are the specific consequences for the user? Thank you for your guidance.

WebAuthn Level 3 § 5.1.3 Step 22 Item 4 states the steps a user agent MUST follow when "conditional" mediation is used in conjunction with required user verification: Let userVerification be the effective user verification requirement for credential creation, a Boolean value, as follows. If pkOptions.authenticatorSelection.userVerification is set to required If options.mediation is set to conditional and user verification cannot be collected during the ceremony, throw a ConstraintError DOMException. Let userVerification be true. On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and user verification is not performed (i.e., the UV bit is 0). Per the spec this results in a registration ceremony failure on the server which is made all the more "annoying" since the credential was created in Passwords forcing a user to then delete the credential. : If the Relying Party requires user verification for this registration, verify that the UV bit of the flags in authData is set. In contrast when I use Google Password Manager + Chrome on a Samsung Galaxy S24 running Android 15, user verification is enforced and the UV bit is 1. Either the UV bit should be 1 after enforcing user verification or an error should be thrown since user verification cannot be performed.

I set up "Sign in with Apple" via REST API according to the documentation. I can log in on my website and everything looks fine for the user. But I receive an email, that my "Sign in with Apple" account has been rejected by my own website. It states, I will have to re-submit my name and email address the next time I log in to this website. I don't see any error messages, no log entries, no HTTP errors anywhere. I also can't find anything in the docs, the emails seem to not be mentioned there, searching for anything with "rejected" in the forum did not yield any helpful result, because they are always about App entries being rejected etc. Did someone experience something similar yet? What's the reason, I'm getting these emails? I get them every time I go through the "Sign in with Apple" flow on my website again.

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!

Hey folks, I'm seeing an issue where my iOS app is getting an "unknown" error when US users try to sign in with Apple. It works fine for users in other countries like the UK, Singapore, and Taiwan. Could it be related to my developer account not being based in the US? Or have I missed something in my settings? Thanks in advance!

I've come across strange behavior with the userID property on the returned credential from a passkey attestation. When performing a cross-device passkey assertion between iOS and Android by scanning the generated QR code on my iPhone with an Android device the returned credential object contains an empty userID. This does not happen when performing an on device or cross-device assertion using two iPhones. Is this expected behavior, or is there something I'm missing here? I couldn't find any more information on this in the documentation. iOS Version: 26.0.1, Android Version: 13

I'm currently reviewing the various DCError cases defined in Apple’s DeviceCheck framework (reference: https://aninterestingwebsite.com/documentation/devicecheck/dcerror-swift.struct). To better understand how to handle these in production, I’m looking for a clear breakdown of: Which specific DCError values can occur during service.generateKey, service.attestKey, and service.generateAssertion The realworld scenarios or conditions that typically cause each error for each method. If anyone has insight on how these errors arise and what conditions trigger them, I’d appreciate your input.

We have been having very high response times in device check device validation service (https://aninterestingwebsite.com/documentation/devicecheck/accessing-and-modifying-per-device-data#Create-the-payload-for-a-device-validation-request) since 17 July at 19:10hs GMT. The service information page says the service was running in green status but that isn't the case and we currenly have stop consuming it. Is it being looked at? Are you aware of this issue? Can you give us an estimate of when it should be working correctly?

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!

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 ?

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?

General: Forums subtopic: Privacy & Security > General Forums tag: App Sandbox App Sandbox documentation App Sandbox Design Guide documentation — This is no longer available from Apple. There’s still some info in there that isn’t covered by the current docs but, with the latest updates, it’s pretty minimal (r. 110052019). Still, if you’re curious, you can consult an old copy [1]. App Sandbox Temporary Exception Entitlements archived documentation — To better understand the role of temporary exception entitlements, see this post. Embedding a command-line tool in a sandboxed app documentation Discovering and diagnosing App Sandbox violations (replaces the Viewing Sandbox Violation Reports forums post) Resolving App Sandbox Inheritance Problems forums post The Case for Sandboxing a Directly Distributed App forums post Implementing Script Attachment in a Sandboxed App forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] For example, this one archived by the Wayback Machine.

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

Hi Apple team, For our iPhone app (App Store build), a small subset of devices report DCAppAttestService.isSupported == false, preventing App Attest from being enabled. Approx. impact: 0.23% (352/153,791) iOS observed: Broadly 15.x–18.7 (also saw a few anomalous entries ios/26.0, likely client logging noise) Device models: Multiple generations (iPhone8–iPhone17); a few iPad7 entries present although the app targets iPhone Questions In iPhone main app context, what conditions can make isSupported return false on iOS 14+? Are there known device/iOS cases where temporary false can occur (SEP/TrustChain related)? Any recommended remediation (e.g., DFU restore)? Could you share logging guidance (Console.app subsystem/keywords) to investigate such cases? What fallback policy do you recommend when isSupported == false (e.g., SE-backed signature + DeviceCheck + risk rules), and any limitations? We can provide sysdiagnose/Console logs and more case details upon request. Thank you, —

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?