Passkeys in iCloud Keychain

RSS for tag

Use public-key-based credentials using the WebAuthn standard that are synced with iCloud Keychain.

Posts under Passkeys in iCloud Keychain tag

200 Posts

Post

Replies

Boosts

Views

Activity

Developer iOS 26.3
Hello, guys. I am going through a situation in which an open validation appears in the system/developer mode and I would like to understand better if this is something normal in this process. Could someone confirm if this type of validation is expected at this stage? I would also like to know what criteria I can observe to be sure that it is legitimate and that I can trust the activation. Thank you in advance for your attention and help. Thank you
2
0
685
Feb ’26
Passkey authentication issues on iPhone when launching login pages via Home Screen shortcuts
Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2
0
1
1.2k
Feb ’26
Passkey mediation conditional get
aID is an ID service for 150+ newspaper sites in Norway. Since the middle of January the average login time with passkeys on our site https://www.aid.no/ has increased for Safari users, the number of logins using passkey in Safari has decreased dramatically. Previously Safari was the browser that provided the best user experience during login, since it triggered fingerprint reader straight away, but this behavior has vanished. Has something changed that we should be aware of, and is there something we can do to make conditional get great again? Without mediation conditional, the passkeys work as expected. In Chrome and Firefox, we get passkey suggestions in the username field, in Safari it's only password suggestions. To make things even stranger, the same code works as it used to in our test environment. It triggers a small popup by the username field and activates the fingerprint reader. If I cancel this, I can click on the Passwords icon and get passkey suggestion there.
1
0
544
Feb ’26
isUserVerifyingPlatformAuthenticatorAvailable returns false on iOS 26.2 Developer Beta
I’m currently developing an application using WKWebView. After updating to iOS 26.2 Developer Beta, the following Web API started returning false: isUserVerifyingPlatformAuthenticatorAvailable MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static This issue did not occur on iOS 26.1 — it only happens on the beta version. Has anyone else encountered this problem or is aware of any related changes? OS: iOS 26.2 beta 3 (23C5044b)
8
4
3.4k
Feb ’26
Third-party Credential Provider Extension AAGUID is overwritten to zeros
I'm developing a passkey manager using ASCredentialProviderViewController. I've set a custom AAGUID in the attestation object during registration: let aaguid = Data([ 0xec, 0x78, 0xfa, 0xe8, 0xb2, 0xe0, 0x56, 0x97, 0x8e, 0x94, 0x7c, 0x77, 0x28, 0xc3, 0x95, 0x00 ]) However, when I test on webauthn.io, the relying party receives: AAGUID: 00000000-0000-0000-0000-000000000000 Provider Name: "iCloud Keychain" It appears that macOS overwrites the AAGUID to all zeros for third-party Credential Provider Extensions. This makes it impossible for relying parties to distinguish between different passkey providers, which is one of the key purposes of AAGUID in the WebAuthn specification. Is this expected behavior? Is there a way for third-party Credential Provider Extensions to use their own registered AAGUID? Environment: macOS 26.2 Xcode 26.2
0
3
792
Feb ’26
ASAuthorizationAccountCreationProvider does not work with 3rd party apps
hello im using the new IOS 26 api for passkey creation ASAuthorizationAccountCreationProvider however it only seems to work with apple's Passwords app. Selecting 3rd party password apps (1Password, google chrome, etc) does not create the passkey. The sign up sheet gives me the option to save in 3rd party apps, but when I select a 3rd party app, I just get the ASAuthorizationError cancelled error? So I dont even know what the problem is? When selecting "Save in Passwords(apple's app)" during the sign up it works fine Has anyone else run into this issue? Is there something I need to do enable 3rd party apps?
7
0
724
Feb ’26
Face ID / Touch ID is requested twice when using Passkey Autofill
When using iCloud Keychain passkeys with WebAuthn (mediation: "conditional") in non-Safari browsers (e.g. Chrome or WKWebView-based browsers), Face ID / Touch ID is requested twice during Passkey Autofill. This issue occurs only when the focused input field shows a numeric keypad–style keyboard, such as: Japanese Kana Chinese Zhuyin With a standard QWERTY keyboard, authentication completes with a single user verification. Notably: Safari completes authentication with one Face ID / Touch ID prompt even with numeric keypad keyboards. Other browsers require two prompts. The issue does not occur with other credential managers (Google Password Manager, 1Password), suggesting this is specific to iCloud Keychain. This issue has been confirmed on the following OS versions: iOS 17.6.1 iOS 18.7.2 iOS 26.2 iOS 26.3 beta Impact This behavior results in a confusing and unintuitive login experience for users relying on Passkey Autofill. Steps to Reproduce: Go to Settings → Keyboards → Keyboards, and set “Japanese – Kana” as the primary keyboard. Enable Face ID / Touch ID, and make sure “Use Face ID / Touch ID For” → “Password Autofill” is enabled. Open Chrome and navigate to https://webauthn.io. Enter a username and tap “Register” to create a passkey using iCloud Keychain. Tap the username field again so that the “Japanese – Kana” keyboard appears and the passkey suggestion created in step 4 is shown. Tap the passkey suggestion. Face ID / Touch ID is requested twice. === This issue has already been reported via Feedback Assistant as FB21726047. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.
1
0
878
Jan ’26
`PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()` returns false in non-Safari browsers on iOS 26.2+
There appears to be a regression or restriction in iOS 26.2 and 26.2.1 regarding the Web Authentication API in third-party browsers (browsers other than Safari). Specifically, the method PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() returns false when called from within non-Safari browsers (e.g., Chrome, Firefox, Edge) on iOS, even when the device supports biometrics (FaceID/TouchID) and Passkeys are enabled. This prevents third-party browsers from correctly detecting Platform Authenticator availability, leading websites to hide Passkey login options or default to cross-device authentication flows instead of using the local device's biometric authenticator. Environment: OS: iOS 26.2, iOS 26.2.1 Device: iPhone 17 Browsers Tested: Chrome iOS and Firefox iOS Steps to Reproduce: Launch Safari on an iOS device running iOS 26.2+. Navigate to https://www.passkeys-debugger.io/. Observe that "Platform Auth" is highlighted in Green (true), indicating the device is eligible for passkey authentication. Launch a non-Safari browser (e.g., Chrome or Firefox) on the same device. Navigate to https://www.passkeys-debugger.io/. Expected Results: "Platform Auth" should be Green (true), matching the behavior in Safari, as the device possesses a built-in platform authenticator. Actual Results: "Platform Auth" is highlighted in Red (false). Impact: This discrepancy fragments the Passkey user experience on iOS. Users preferring third-party browsers are unable to utilize the seamless on-device biometric authentication that is available in Safari. It forces developers to implement complex fallbacks or results in users believing their device is incompatible with Passkeys.
1
0
682
Jan ’26
Credential Provider Extension should allow BE=0, BS=0 for device-bound passkeys
In these threads, it was clarified that Credential Provider Extensions must set both Backup Eligible (BE) and Backup State (BS) flags to 1 in authenticator data: https://developer.apple.com/forums/thread/745605 https://developer.apple.com/forums/thread/787629 However, I'm developing a passkey manager that intentionally stores credentials only on the local device. My implementation uses: kSecAttrAccessibleWhenUnlockedThisDeviceOnly for keychain items kSecAttrTokenIDSecureEnclave for private keys No iCloud sync or backup These credentials are, by definition, single-device credentials. According to the WebAuthn specification, they should be represented with BE=0, BS=0. Currently, I'm forced to set BE=1, BS=1 to make the extension work, which misrepresents the actual backup status to relying parties. This is problematic because: Servers using BE/BS flags for security policies will incorrectly classify these as synced passkeys Users who specifically want device-bound credentials for higher security cannot get accurate flag representation Request: Please allow Credential Provider Extensions to return credentials with BE=0, BS=0 for legitimate device-bound passkey implementations. Environment: macOS 26.2 (25C56), Xcode 26.2 (17C52)
0
3
1.1k
Jan ’26
Passkey's userVerificationPreference in authentication
Hi, I'm using webauthn.io to test my macOS Passkey application. When registering a passkey whichever value I set for User Verification, that's what I get when I check registrationRequest.userVerificationPreference on prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest). However, when authenticating my passkey I can never get discouraged UV on prepareInterfaceToProvideCredential(for credentialRequest: any ASCredentialRequest). In the WWDC 2022 Meet Passkeys video, it is stated that Apple will always require UV when biometrics are available. I use a Macbook Pro with TouchID, but if I'm working with my lid closed, shouldn't I be able to get .discouraged?
0
1
598
Jan ’26
WebAuthn
The passkey authentication dialog appears, and after unlocking with Touch ID, the dialog closes without any notification of success or failure. This issue occurs with high frequency. access to the https://passkeys-demo.appspot.com/ register account and create passkey. logoff access to the url again you can see the passkey dialog unlock device then the dialog disappears nothing happens reload the page proceed 5) to 6) nothing happens or success webauthn.
4
1
1.7k
Jan ’26
how can i pass the passkeyRegistration back to the user agent(web)
After registe Passkey with webauthn library, i create a passkeyRegistration with follow, let passkeyRegistration = ASPasskeyRegistrationCredential(relyingParty: serviceIdentifier, clientDataHash: clientDataHashSign, credentialID: credentialId, attestationObject: attestationObject) and then completeRegistrationRequest like that, extensionContext.completeRegistrationRequest(using: passkeyRegistration) But a bad outcome occurred from user agent. NotAllowedError:The request is not allowed by the user agent or the platform in the current context. And the return data rawID & credentialPublicKey is empty,
1
1
1.1k
Jan ’26
macOS 14.8 Keychain Import Fails for PKCS#12 Files Generated with OpenSSL 3.4.0
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 );
1
0
665
Jan ’26
How to regenerate passkey for appstoreconnect.apple.com
When logging into appstoreconnect I get the option to use a password or passkey: Password works fine. However passkey always results in: This is probably because I don't actually have any passkeys: So I think what is happening is that Apple thinks I have a passkey, which is why it's offering that as an option. I can't see any option to create a passkey, or regenerate one. I'm not sure how I've ended up in this state. I have a vague memory that sometime years ago when passkeys were first introduced on appstoreconnect that I tried to create one, but because it wouldn't let me store it in BitWarden, I backed out. It's not a major problem because I can still log in using password. But I'm worried in case some time in the future passkey becomes the only option. Does anyone know of any way I can reset or regenerate my passkey for appstoreconnect?
2
2
608
Dec ’25
the passkey suggestion does not appear; instead, the password suggestion appears on iPhone.
Create shortcut to open chrome with url and put it on the desktop. Tap the shortcut. Tap the username text field. When launching Safari from an iOS shortcut on an iOS device with a valid passkey registered, the passkey suggestion does not appear; instead, the password suggestion appears sometimes.
0
1
1.1k
Dec ’25
Passkey issue- Unable to verify webcredentials
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!
1
0
707
Nov ’25
Xcode 26 Beta Simulator Bug: Issue with Fast Account Creation Using Passkeys
Hi everyone, We’re testing the new iOS 26 capability, Performing Fast Account Creation with Passkeys, using the sample project provided here: Performing Fast Account Creation with Passkeys. When running the project on the iOS 26 simulator and tapping the "Sign Up" button, we encounter the following error: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1010.) From the header file, this error is described as: /// ASAuthorizationError.h /// This error signals that the device is not currently set up to create passkeys. ASAuthorizationErrorDeviceNotConfiguredForPasskeyCreation AS_API_AVAILABLE(ios(19.0), macos(16.0), visionos(3.0)) = 1010, We’ve tested this on both Xcode 26 Beta 1 and Beta 2, and the error persists on the simulator in both versions. However, when testing on a physical iOS 26 device, everything works as expected, just like in the WWDC demo. Could this issue be related to missing simulator settings? Or is it a potential bug in the simulator? Any advice would be greatly appreciated. Thanks in advance!
5
0
817
Nov ’25
Is there a way to hide the 'Save to another device' option during iOS WebAuthn registration?
Hello, I am currently implementing a biometric authentication registration flow using WebAuthn. I am using ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest, and I would like to know if there is a way to hide the "Save to another device" option that appears during the registration process. Specifically, I want to guide users to save the passkey only locally on their device, without prompting them to save it to iCloud Keychain or another device. If there is a way to hide this option or if there is a recommended approach to achieve this, I would greatly appreciate your guidance. Also, if this is not possible due to iOS version or API limitations, I would be grateful if you could share any best practices for limiting user options in this scenario. If anyone has experienced a similar issue, your advice would be very helpful. Thank you in advance.
1
0
1.4k
Oct ’25
How to Hide the "Save to Another Device" Option During Passkey Registration?
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!
1
0
418
Oct ’25
Developer iOS 26.3
Hello, guys. I am going through a situation in which an open validation appears in the system/developer mode and I would like to understand better if this is something normal in this process. Could someone confirm if this type of validation is expected at this stage? I would also like to know what criteria I can observe to be sure that it is legitimate and that I can trust the activation. Thank you in advance for your attention and help. Thank you
Replies
2
Boosts
0
Views
685
Activity
Feb ’26
Passkey authentication issues on iPhone when launching login pages via Home Screen shortcuts
Summary: We are facing a serious issue on iPhone where multiple passkey authentication problems occur when accessing passkey-enabled login pages via shortcuts placed on the iPhone Home Screen. These issues may also occur when opening the same pages directly in a standard browser window. However, launching the login pages from a Home Screen shortcut appears to increase the likelihood of encountering these issues. Affected Services (examples, not exhaustive): Amazon GitHub Adobe Observed Issues: Issue 1: A passkey authentication dialog/popup shows two times without any user operation: What happens due to this issue: Login does not complete after the first passkey authentication. A second passkey authentication UI automatically appears. Completing or canceling the second authentication allows the login to proceed. Issue 2: Login remains stuck until the user manually invokes passkey again What happens due to this issue: The login page does not advance after the first authentication. The user must tap the ID/username field again to manually trigger the passkey UI. Completing the second authentication enables login. Issue 3: Automatic second authentication occurs, but login still fails What happens due to this issue: A second automatic authentication UI appears. Login still does not complete. Tapping the ID field no longer opens the passkey UI; instead, the password auto-fill panel appears. Passkey login becomes impossible. Observed reproduction steps (not guaranteed but most consistently observed): On iPhone, navigate to a passkey-enabled login page (e.g., Amazon, GitHub, Adobe) using a browser. Create a shortcut from the browser's share menu and place it on the Home Screen. Launch the login page from the Home Screen shortcut. Tap the ID/username field to invoke the passkey prompt. Complete passkey authentication. → One of the issues described above occurs. Environment: Device: iPhone SE OS: iOS 18.6.2
Replies
0
Boosts
1
Views
1.2k
Activity
Feb ’26
Passkey mediation conditional get
aID is an ID service for 150+ newspaper sites in Norway. Since the middle of January the average login time with passkeys on our site https://www.aid.no/ has increased for Safari users, the number of logins using passkey in Safari has decreased dramatically. Previously Safari was the browser that provided the best user experience during login, since it triggered fingerprint reader straight away, but this behavior has vanished. Has something changed that we should be aware of, and is there something we can do to make conditional get great again? Without mediation conditional, the passkeys work as expected. In Chrome and Firefox, we get passkey suggestions in the username field, in Safari it's only password suggestions. To make things even stranger, the same code works as it used to in our test environment. It triggers a small popup by the username field and activates the fingerprint reader. If I cancel this, I can click on the Passwords icon and get passkey suggestion there.
Replies
1
Boosts
0
Views
544
Activity
Feb ’26
isUserVerifyingPlatformAuthenticatorAvailable returns false on iOS 26.2 Developer Beta
I’m currently developing an application using WKWebView. After updating to iOS 26.2 Developer Beta, the following Web API started returning false: isUserVerifyingPlatformAuthenticatorAvailable MDN: https://developer.mozilla.org/ja/docs/Web/API/PublicKeyCredential/isUserVerifyingPlatformAuthenticatorAvailable_static This issue did not occur on iOS 26.1 — it only happens on the beta version. Has anyone else encountered this problem or is aware of any related changes? OS: iOS 26.2 beta 3 (23C5044b)
Replies
8
Boosts
4
Views
3.4k
Activity
Feb ’26
Third-party Credential Provider Extension AAGUID is overwritten to zeros
I'm developing a passkey manager using ASCredentialProviderViewController. I've set a custom AAGUID in the attestation object during registration: let aaguid = Data([ 0xec, 0x78, 0xfa, 0xe8, 0xb2, 0xe0, 0x56, 0x97, 0x8e, 0x94, 0x7c, 0x77, 0x28, 0xc3, 0x95, 0x00 ]) However, when I test on webauthn.io, the relying party receives: AAGUID: 00000000-0000-0000-0000-000000000000 Provider Name: "iCloud Keychain" It appears that macOS overwrites the AAGUID to all zeros for third-party Credential Provider Extensions. This makes it impossible for relying parties to distinguish between different passkey providers, which is one of the key purposes of AAGUID in the WebAuthn specification. Is this expected behavior? Is there a way for third-party Credential Provider Extensions to use their own registered AAGUID? Environment: macOS 26.2 Xcode 26.2
Replies
0
Boosts
3
Views
792
Activity
Feb ’26
ASAuthorizationAccountCreationProvider does not work with 3rd party apps
hello im using the new IOS 26 api for passkey creation ASAuthorizationAccountCreationProvider however it only seems to work with apple's Passwords app. Selecting 3rd party password apps (1Password, google chrome, etc) does not create the passkey. The sign up sheet gives me the option to save in 3rd party apps, but when I select a 3rd party app, I just get the ASAuthorizationError cancelled error? So I dont even know what the problem is? When selecting "Save in Passwords(apple's app)" during the sign up it works fine Has anyone else run into this issue? Is there something I need to do enable 3rd party apps?
Replies
7
Boosts
0
Views
724
Activity
Feb ’26
Face ID / Touch ID is requested twice when using Passkey Autofill
When using iCloud Keychain passkeys with WebAuthn (mediation: "conditional") in non-Safari browsers (e.g. Chrome or WKWebView-based browsers), Face ID / Touch ID is requested twice during Passkey Autofill. This issue occurs only when the focused input field shows a numeric keypad–style keyboard, such as: Japanese Kana Chinese Zhuyin With a standard QWERTY keyboard, authentication completes with a single user verification. Notably: Safari completes authentication with one Face ID / Touch ID prompt even with numeric keypad keyboards. Other browsers require two prompts. The issue does not occur with other credential managers (Google Password Manager, 1Password), suggesting this is specific to iCloud Keychain. This issue has been confirmed on the following OS versions: iOS 17.6.1 iOS 18.7.2 iOS 26.2 iOS 26.3 beta Impact This behavior results in a confusing and unintuitive login experience for users relying on Passkey Autofill. Steps to Reproduce: Go to Settings → Keyboards → Keyboards, and set “Japanese – Kana” as the primary keyboard. Enable Face ID / Touch ID, and make sure “Use Face ID / Touch ID For” → “Password Autofill” is enabled. Open Chrome and navigate to https://webauthn.io. Enter a username and tap “Register” to create a passkey using iCloud Keychain. Tap the username field again so that the “Japanese – Kana” keyboard appears and the passkey suggestion created in step 4 is shown. Tap the passkey suggestion. Face ID / Touch ID is requested twice. === This issue has already been reported via Feedback Assistant as FB21726047. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.
Replies
1
Boosts
0
Views
878
Activity
Jan ’26
`PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()` returns false in non-Safari browsers on iOS 26.2+
There appears to be a regression or restriction in iOS 26.2 and 26.2.1 regarding the Web Authentication API in third-party browsers (browsers other than Safari). Specifically, the method PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() returns false when called from within non-Safari browsers (e.g., Chrome, Firefox, Edge) on iOS, even when the device supports biometrics (FaceID/TouchID) and Passkeys are enabled. This prevents third-party browsers from correctly detecting Platform Authenticator availability, leading websites to hide Passkey login options or default to cross-device authentication flows instead of using the local device's biometric authenticator. Environment: OS: iOS 26.2, iOS 26.2.1 Device: iPhone 17 Browsers Tested: Chrome iOS and Firefox iOS Steps to Reproduce: Launch Safari on an iOS device running iOS 26.2+. Navigate to https://www.passkeys-debugger.io/. Observe that "Platform Auth" is highlighted in Green (true), indicating the device is eligible for passkey authentication. Launch a non-Safari browser (e.g., Chrome or Firefox) on the same device. Navigate to https://www.passkeys-debugger.io/. Expected Results: "Platform Auth" should be Green (true), matching the behavior in Safari, as the device possesses a built-in platform authenticator. Actual Results: "Platform Auth" is highlighted in Red (false). Impact: This discrepancy fragments the Passkey user experience on iOS. Users preferring third-party browsers are unable to utilize the seamless on-device biometric authentication that is available in Safari. It forces developers to implement complex fallbacks or results in users believing their device is incompatible with Passkeys.
Replies
1
Boosts
0
Views
682
Activity
Jan ’26
Credential Provider Extension should allow BE=0, BS=0 for device-bound passkeys
In these threads, it was clarified that Credential Provider Extensions must set both Backup Eligible (BE) and Backup State (BS) flags to 1 in authenticator data: https://developer.apple.com/forums/thread/745605 https://developer.apple.com/forums/thread/787629 However, I'm developing a passkey manager that intentionally stores credentials only on the local device. My implementation uses: kSecAttrAccessibleWhenUnlockedThisDeviceOnly for keychain items kSecAttrTokenIDSecureEnclave for private keys No iCloud sync or backup These credentials are, by definition, single-device credentials. According to the WebAuthn specification, they should be represented with BE=0, BS=0. Currently, I'm forced to set BE=1, BS=1 to make the extension work, which misrepresents the actual backup status to relying parties. This is problematic because: Servers using BE/BS flags for security policies will incorrectly classify these as synced passkeys Users who specifically want device-bound credentials for higher security cannot get accurate flag representation Request: Please allow Credential Provider Extensions to return credentials with BE=0, BS=0 for legitimate device-bound passkey implementations. Environment: macOS 26.2 (25C56), Xcode 26.2 (17C52)
Replies
0
Boosts
3
Views
1.1k
Activity
Jan ’26
Passkey's userVerificationPreference in authentication
Hi, I'm using webauthn.io to test my macOS Passkey application. When registering a passkey whichever value I set for User Verification, that's what I get when I check registrationRequest.userVerificationPreference on prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest). However, when authenticating my passkey I can never get discouraged UV on prepareInterfaceToProvideCredential(for credentialRequest: any ASCredentialRequest). In the WWDC 2022 Meet Passkeys video, it is stated that Apple will always require UV when biometrics are available. I use a Macbook Pro with TouchID, but if I'm working with my lid closed, shouldn't I be able to get .discouraged?
Replies
0
Boosts
1
Views
598
Activity
Jan ’26
WebAuthn
The passkey authentication dialog appears, and after unlocking with Touch ID, the dialog closes without any notification of success or failure. This issue occurs with high frequency. access to the https://passkeys-demo.appspot.com/ register account and create passkey. logoff access to the url again you can see the passkey dialog unlock device then the dialog disappears nothing happens reload the page proceed 5) to 6) nothing happens or success webauthn.
Replies
4
Boosts
1
Views
1.7k
Activity
Jan ’26
how can i pass the passkeyRegistration back to the user agent(web)
After registe Passkey with webauthn library, i create a passkeyRegistration with follow, let passkeyRegistration = ASPasskeyRegistrationCredential(relyingParty: serviceIdentifier, clientDataHash: clientDataHashSign, credentialID: credentialId, attestationObject: attestationObject) and then completeRegistrationRequest like that, extensionContext.completeRegistrationRequest(using: passkeyRegistration) But a bad outcome occurred from user agent. NotAllowedError:The request is not allowed by the user agent or the platform in the current context. And the return data rawID & credentialPublicKey is empty,
Replies
1
Boosts
1
Views
1.1k
Activity
Jan ’26
macOS 14.8 Keychain Import Fails for PKCS#12 Files Generated with OpenSSL 3.4.0
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 );
Replies
1
Boosts
0
Views
665
Activity
Jan ’26
How to regenerate passkey for appstoreconnect.apple.com
When logging into appstoreconnect I get the option to use a password or passkey: Password works fine. However passkey always results in: This is probably because I don't actually have any passkeys: So I think what is happening is that Apple thinks I have a passkey, which is why it's offering that as an option. I can't see any option to create a passkey, or regenerate one. I'm not sure how I've ended up in this state. I have a vague memory that sometime years ago when passkeys were first introduced on appstoreconnect that I tried to create one, but because it wouldn't let me store it in BitWarden, I backed out. It's not a major problem because I can still log in using password. But I'm worried in case some time in the future passkey becomes the only option. Does anyone know of any way I can reset or regenerate my passkey for appstoreconnect?
Replies
2
Boosts
2
Views
608
Activity
Dec ’25
the passkey suggestion does not appear; instead, the password suggestion appears on iPhone.
Create shortcut to open chrome with url and put it on the desktop. Tap the shortcut. Tap the username text field. When launching Safari from an iOS shortcut on an iOS device with a valid passkey registered, the passkey suggestion does not appear; instead, the password suggestion appears sometimes.
Replies
0
Boosts
1
Views
1.1k
Activity
Dec ’25
Passkey issue- Unable to verify webcredentials
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!
Replies
1
Boosts
0
Views
707
Activity
Nov ’25
Xcode 26 Beta Simulator Bug: Issue with Fast Account Creation Using Passkeys
Hi everyone, We’re testing the new iOS 26 capability, Performing Fast Account Creation with Passkeys, using the sample project provided here: Performing Fast Account Creation with Passkeys. When running the project on the iOS 26 simulator and tapping the "Sign Up" button, we encounter the following error: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1010.) From the header file, this error is described as: /// ASAuthorizationError.h /// This error signals that the device is not currently set up to create passkeys. ASAuthorizationErrorDeviceNotConfiguredForPasskeyCreation AS_API_AVAILABLE(ios(19.0), macos(16.0), visionos(3.0)) = 1010, We’ve tested this on both Xcode 26 Beta 1 and Beta 2, and the error persists on the simulator in both versions. However, when testing on a physical iOS 26 device, everything works as expected, just like in the WWDC demo. Could this issue be related to missing simulator settings? Or is it a potential bug in the simulator? Any advice would be greatly appreciated. Thanks in advance!
Replies
5
Boosts
0
Views
817
Activity
Nov ’25
Passkey - another device
Hi! Is it possible to disable the option for users to 'Sign in with Another Device'? I encounter this message during the authentication process and I want to prevent it from appearing. I appreciate your help and look forward to your response.
Replies
1
Boosts
1
Views
1.4k
Activity
Oct ’25
Is there a way to hide the 'Save to another device' option during iOS WebAuthn registration?
Hello, I am currently implementing a biometric authentication registration flow using WebAuthn. I am using ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest, and I would like to know if there is a way to hide the "Save to another device" option that appears during the registration process. Specifically, I want to guide users to save the passkey only locally on their device, without prompting them to save it to iCloud Keychain or another device. If there is a way to hide this option or if there is a recommended approach to achieve this, I would greatly appreciate your guidance. Also, if this is not possible due to iOS version or API limitations, I would be grateful if you could share any best practices for limiting user options in this scenario. If anyone has experienced a similar issue, your advice would be very helpful. Thank you in advance.
Replies
1
Boosts
0
Views
1.4k
Activity
Oct ’25
How to Hide the "Save to Another Device" Option During Passkey Registration?
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!
Replies
1
Boosts
0
Views
418
Activity
Oct ’25