we can get token but when send to verity from apple. it reture Error : {"responseCode":"400","responseMessage":"Missing or incorrectly formatted device token payload"}

Hey all, Question for the masses.... Does the Yubikey authentication have a OS dependency and it only works with a stable, public OS? Does Azure/Okta/Yubikey beta OS26? My CEO installed iPadOS 26 on his iPad and was not able to authenticate via Yubikey into our company environment. I ran the same scenario on my iPad using iPadOS 26 and I had the same results. Downgrading to iPAdOS doesn't pose these issues. I'm assuming something isn't fine-tuned yet?

Seeing the following error when attempting automatic passkey upgrade - [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. We're trying to enable Automatic passkey upgrade (https://aninterestingwebsite.com/videos/play/wwdc2024/10125/?time=38) for our website but it's not working from our testing on iOS 18.2 and 18.3 Beta Safari. The flow on our website looks like: the customers use autofill to fill out email and password on the sign-in page (abc.com/signin) PublicKeyCredential.getClientCapabilities is called to check if conditionalCreate supported. land on another page of our website (abc.com/pageX), which calls navigator.credentials.create with mediation conditional (Right after sign-in). We checked that we followed the steps in above video: Allow automatic passkey upgrades is enabled, mediation is set to conditional and password autofill is used to signed in. However, Safari threw an error [Warning] NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Can Apple help guide us if anything is missed here?

Hello Team, We’ve recently started receiving reports from our customer base (Trellix) regarding issues with Full Disk Access (FDA) for Trellix binaries on macOS devices running Tahoe 26.1 (released on November 3, 2025). The issue occurs when users attempt to add Trellix CLI binaries under FDA to grant the required permissions; the binaries fail to appear under the FDA settings, even after selection. Upon further investigation, this appears to be a macOS 26.1–specific issue and not observed in earlier versions. Similar reports have been noted across various forums, indicating that the issue affects multiple binaries, not just Trellix: Some of the discussions on the same issue I see online. https://aninterestingwebsite.com/forums/thread/806187 https://aninterestingwebsite.com/forums/thread/806156 https://forum.logik.tv/t/macos-26-1-installation-issue-wait-before-updating/13761 https://www.reddit.com/r/MacOS/comments/1os1ph3/cant_add_anything_to_privacy_security_full_disk/ I have also logged FB21009024 for the same. We would like to understand when we can expect this to be fixed, since the issue persists even in 26.2 Beta and also whether the workaround of dragging and dropping the binaries can still be suggested?

I'm looking to implement USB monitoring for FIDO2 authentication through a custom Authorization Plugin, specifically for the below ones. This plugin applies to the following macOS authorization mechanisms: system.login.console — login window authentication system.login.screensaver — screensaver unlock authentication The goal is to build a GUI AuthPlugin, an authorization plugin that presents a custom window prompting the user to "Insert your FIDO key”. Additionally, the plugin should detect when the FIDO2 device is removed and respond accordingly. Additional Info: We have already developed a custom authorization plugin which is a primary authentication using OTP at login and Lock Screen. We are now extending to include FIDO2 support as a primary. Our custom authorization plugin is designed to replace the default loginwindow:login mechanism with a custom implementation. Question: Is there a reliable approach to achieve the USB monitoring functionality through a custom authorization plugin? Any guidance or pointers on this would be greatly appreciated.

Hi everyone, I’m looking for clarification on best practices for storing API keys in an iOS app — for example, keys used with RevenueCat, PostHog, AWS Rekognition, barcode scanners, and similar third-party services. I understand that hard-coding API keys directly in the app’s source code is a bad idea, since they can be extracted from the binary. However, using a .plist file doesn’t seem secure either, as it’s still bundled with the app and can be inspected. I’m wondering: What are Apple’s recommended approaches for managing these kinds of keys? Does Xcode Cloud offer a built-in or best-practice method for securely injecting environment variables or secrets at build time? Would using an external service like AWS Secrets Manager or another server-side solution make sense for this use case? Any insights or examples of how others are handling this securely within Apple’s ecosystem would be greatly appreciated. Thanks for considering my questions! — Paul

I am trying to setup remote Java debugging between two machines running macOS (15.6 and 26). I am able to get the Java program to listen on a socket. However, I can connect to that socket only from the same machine, not from another machine on my local network. I use nc to test the connection. It reports Connection refused when trying to connect from the other machine. This issue sounds like it could be caused by the Java program lacking Local Network system permission. I am familiar with that issue arising when a program attempts to connect to a port on the local network. In that case, a dialog is displayed and System Settings can be used to grant Local Network permission to the client program. I don't know whether the same permission is required on the program that is receiving client requests. If it is, then I don't know how to grant that permission. There is no dialog, and System Settings does not provide any obvious way to grant permission to a program that I specify. Note that a Java application is a program run by the java command, not a bundled application. The java command contains a hard-wired Info.plist which, annoyingly, requests permission to use the microphone, but not Local Network access.

Hi everyone, I'm currently working on a native macOS app (built with SwiftUI) and I'm trying to implement Password AutoFill functionality so users can use their saved credentials from Keychain or third-party password managers. I've gone through Apple's documentation, WWDC sessions, and sample code, but I've noticed that the resources primarily focus on iOS and web implementations. There's very limited guidance specifically for macOS. I've set up: Associated Domains entitlement with the webcredentials: service The apple-app-site-association file on my server TextField with .textContentType(.username) and SecureField with .textContentType(.password) However, I'm still not seeing the expected AutoFill behavior on macOS like I would on iOS. Has anyone successfully implemented Password AutoFill on a native macOS app? Are there any macOS-specific considerations or additional steps required that differ from iOS? Any guidance, sample code, or pointers to documentation I might have missed would be greatly appreciated.

I noticed, that even though my AutoFill Credential Provider Extension works with Safari for both Passwords and Passkeys, it doesn't work in context menus inside arbitrary textfields, meanwhile the same is true for the Apple Passwords app. This is a great hit to AutoFill productivity, as my extension is unable to fill textfields by just going to the context menu and clicking AutoFill > Passwords.. Is this a feature only available to Apple via private APIs, or is this something I can interface with? I checked and the Passwords app does use some undocumented but non-private entitlements: [Key] com.apple.authentication-services.access-credential-identities [Value] [Bool] true I also checked the responsible executable for some hints (AutoFillPanelService) however found nothing that would lead me to believe this is a public extension point. Another idea I had was trying to use a macOS Service for this, however Services in the "General" category won't show up in any context menu, only in the Application's Main Menu.

We are developing an app that uses Authentication Services to authenticate users. According to the documentation, this framework will open the default web browser if it supports auth session handling, and Safari otherwise. This is not entirely true, and users will be frustrated! macOS version: Sequoia 15.5; Safari version: 18.5. When: The default browser is not Safari, and supports auth session handling (Google Chrome and Microsoft Edge as examples); and - The Safari app is already running; The auth flow will: Present the confirmation dialog box with the default browser icon. Good! Open a Safari window, instead of the default browser's one. Bad! Respond with "User Cancelled" error to the app, after making the end user believe the auth was good. Very Bad!! If the app retries the auth session, the default browser window will open as expected, and it will work as expected. However, requiring users to authenticate twice is a very bad users experience... This issue does not reproduce, when either: Safari is not running at the moment of auth session start; The default browser does not support auth session handling; or - Safari is the default browser. Fellow developers, be warned! Apple engineers, feedback #18426939 is waiting for you. Cheers!

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?

I'm working on integrating Passkey functionality into my iOS app (targeting iOS 16.0+), and I'm facing an issue where the system dialog still shows the "Save to another device" option during Passkey registration. I want to hide this option to force users to create Passkeys only on the current device. 1. My Current Registration Implementation Here’s the code I’m using to create a Passkey registration request. I’ve tried to use ASAuthorizationPlatformPublicKeyCredentialProvider (which is supposed to target platform authenticators like Face ID/Touch ID), but the "Save to another device" option still appears: `// Initialize provider for platform authenticators let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: domain) // Create registration request let registrationRequest = provider.createCredentialRegistrationRequest( challenge: challenge, name: username, userID: userId ) // Optional configurations (tried these but no effect on "another device" option) registrationRequest.displayName = "Test Device" registrationRequest.userVerificationPreference = .required registrationRequest.attestationPreference = .none // Set up authorization controller let authController = ASAuthorizationController(authorizationRequests: [registrationRequest]) let delegate = PasskeyRegistrationDelegate(completion: completion) authController.delegate = delegate // Trigger the registration flow authController.performRequests(options: .preferImmediatelyAvailableCredentials)` 2. Observation from Authentication Flow (Working as Expected) During the Passkey authentication flow (not registration), I can successfully hide the "Use another device" option by specifying allowedCredentials in the ASAuthorizationPlatformPublicKeyCredentialAssertionRequest. Here’s a simplified example of that working code: let assertionRequest = provider.createCredentialAssertionRequest(challenge: challenge) assertionRequest.allowedCredentials = allowedCredentials After adding allowedCredentials, the system dialog no longer shows cross-device options—this is exactly the behavior I want for registration. 3. My Questions Is there a similar parameter to allowedCredentials (from authentication) that I can use during registration to hide the "Save to another device" option? Did I miss any configuration in the registration request (e.g., authenticatorAttachment or other properties) that forces the flow to use only the current device’s platform authenticator? Are there any system-level constraints or WebAuthn standards I’m overlooking that cause the "Save to another device" option to persist during registration? Any insights or code examples would be greatly appreciated!

Hi. I enter a password using the security command at the command line. It appears in the keychain access app, but not in the passwords app. I don't understand why. rickhedin@Ricks-MacBook-Pro zalando % security add-generic-password -U -s "birds" -a "cats" -w "dogs" rickhedin@Ricks-MacBook-Pro zalando % rickhedin@Ricks-MacBook-Pro zalando % security find-generic-password -s "birds" -wa "cats" dogs rickhedin@Ricks-MacBook-Pro zalando % I'm told the two apps are two views of the same data, so I guess some filter must be being applied?

Hello everyone, In my application, i have implemented authentication using ASWebauthenticationSession. However, when redirecting the user to a WKWebView, no cookies are shared, causing the session to be lost and requiring the user to log in again. Is there a way to share cookies between the two? If not, what would be the best approach to set up authentication that ensures SSO when switching to a WebView ? Thank you very much for your help !

Hey everyone, I'm hitting a really frustrating issue with App Attest. My app was working perfectly with DCAppAttestService on October 12th, but starting October 13th it started failing with DCError Code 2 "Failed to fetch App UUID" at DCAppAttestController.m:153. The weird part is I didn't change any code - same implementation, same device, same everything. I've tried switching between development and production entitlement modes, re-registered my device in the Developer Portal, created fresh provisioning profiles with App Attest capability, and verified that my App ID has App Attest enabled. DCAppAttestService.isSupported returns true, so the device supports it. Has anyone else run into this? This is blocking my production launch and I'm not sure if it's something on my end or an Apple infrastructure issue.

Hello, I’m storing some values in the Keychain with the attribute ‘ksecattraccessibleafterfirstunlockthisdeviceonly’ (https://aninterestingwebsite.com/documentation/security/ksecattraccessibleafterfirstunlockthisdeviceonly). When I migrate user data between iPhones via iCloud, this behaves as expected and the keys are not preserved. However, when I migrate using a direct connection between two devices, the keys are preserved, which seems to contradict the attribute’s intent. Is this a known behavior, and if so, is there a workaround?

Since Sun 15th Jun 04:30 (UTC+7) we received lots of following error that causes our device test failure. Could Apple please investigate further? ############################# Operations could not be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable)

Hi, is it somehow possible to access a key that was generated by the DCAppAttestService generateKey() function? I need to be 100% sure that no actor from within or outside of my app can access the generated key with the DeviceCheck Framework. It would also be helpful to get some official resources to the topic. Thank you in advance, Mike

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,

I’m looking for clarification on how rate limiting works for the App Attest service, especially in production environments. According to the entitlement documentation (https://aninterestingwebsite.com/documentation/BundleResources/Entitlements/com.apple.developer.devicecheck.appattest-environment), iOS ignores the environment setting once an app is distributed through TestFlight, the App Store, or Enterprise distribution, and always contacts the production App Attest endpoint. With that context, I have two questions: Rate‑Limiting Thresholds How exactly does rate limiting work for App Attest? Is there a defined threshold beyond which attestation requests begin to fail? The "Preparing to Use the App Attest Service" documentation (https://aninterestingwebsite.com/documentation/devicecheck/preparing-to-use-the-app-attest-service) recommends ramping up no more than 10 million users per day per app, but I’m trying to understand what practical limits or failure conditions developers should expect. Per‑AppID Budgeting If multiple apps have different App IDs, do they each receive their own independent attestation budget/rate limit? Or is the rate limiting shared across all apps under the same developer account?