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)

Hello I'm using Auth0 for handling auth in my app When the user wants to sign in, it will show the auth system pop-up And when the user wants to log out it shows the same pop-up My issue is how to replace the Sign In text in this pop-up to show Sign Out instead of Sign In when the user wants to sign out?

Hello everyone, I'm developing a FIDO2 service using the AuthenticationServices framework. I've run into an issue when a user manually deletes a passkey from their password manager. When this happens, the ASAuthorizationError I get doesn't clearly indicate that the passkey is missing. The error code is 1001, and the localizedDescription is "The operation couldn't be completed. No credentials available for login." The userInfo also contains "NSLocalizedFailureReason": "No credentials available for login." My concern is that these localized strings will change depending on the user's device language, making it unreliable for me to programmatically check for a "no credentials" scenario. Is there a more precise way to determine that the user has no passkey, without relying on localized string values? Thank you for your help.

Hi all, I’m building a password manager app for iOS. The app implements an ASCredentialProviderExtension and has the entitlement com.apple.developer.authentication-services.autofill-credential-provider. From a UX perspective, I’d like to help users enable my app under: Settings → General → AutoFill & Passwords What I’ve observed: Calling UIApplication.openSettingsURLString only opens my app’s own Settings page, not the AutoFill list. Some apps (e.g. Google Authenticator) appear to redirect users directly into the AutoFill Passwords & Passkeys screen when you tap “Enable AutoFill.” 1Password goes even further: when you tap “Enable” in 1Password App, it shows a system pop-up, prompts for Face ID, and then enables 1Password as the AutoFill provider without the user ever leaving the app. Questions: Is there a public API or entitlement that allows apps to deep-link users directly to the AutoFill Passwords & Passkeys screen? Is there a supported API to programmatically request that my app be enabled as an AutoFill provider (similar to what 1Password seems to achieve)? If not, what is the recommended approach for guiding users through this flow? Thanks in advance!

Hi Apple Devs, For our app, we utilize passkeys for account creation (not MFA). This is mainly for user privacy, as there is 0 PII associated with passkey account creation, but it additionally also satisfies the 4.8: Login Services requirement for the App Store. However, we're getting blocked in Apple Review. Because the AASA does not get fetched immediately upon app install, the reviewers are not able to create an account immediately via passkeys, and then they reject the build. I'm optimistic I can mitigate the above. But even if we pass Apple Review, this is a pretty catastrophic issue for user security and experience. There are reports that 5% of users cannot create passkeys immediately (https://developer.apple.com/forums/thread/756740). That is a nontrivial amount of users, and this large of an amount distorts how app developers design onboarding and authentication flows towards less secure experiences: App developers are incentivized to not require MFA setup on account creation because requiring it causes significant churn, which is bad for user security. If they continue with it anyways, for mitigation, developers are essentially forced to add in copy into their app saying something along the lines of "We have no ability to force Apple to fetch the config required to continue sign up, so try again in a few minutes, you'll just have to wait." You can't even implement a fallback method. There's no way to check if the AASA is available before launching the ASAuthorizationController so you can't mitigate a portion of users encountering an error!! Any app that wants to use the PRF extension to encrypt core functionality (again, good for user privacy) simply cannot exist because the app simply does not work for an unspecified amount of time for a nontrivial portion of users. It feels like a. Apple should provide a syscall API that we can call to force SWCD to verify the AASA or b. implement a config based on package name for the app store such that the installation will immediately include a verified AASA from Apple's CDN. Flicking the config on would require talking with Apple. If this existed, this entire class of error would go away. It feels pretty shocking that there isn't a mitigation in place for this already given that it incentivizes app developers to pursue strictly less secure and less private authentication practices.

Using the simplified sign-in with tvOS and a third party password manager, I receive a complete ASPasswordCredential, and I can easily log into my app. When I do the same thing but with Apple's password manager as the source, I receive an ASPasswordCredential that includes the email address, but the password is an empty string. I have tried deleting the credentials from Apple Passwords and regenerating them with a new login to the app's website. I have tried restarting my iPhone. Is this the expected behavior? How should I be getting a password from Apple's Password app with an ASAuthorizationPasswordRequest?

Hi, I've been unable to reproduce an issue that is getting our new app flagged in App Review. Login/Registration via passkeys fails for the testers every time. We've provided an alternative sign in method, but I'm still curious why this might happen. When testing locally and in TestFlight, registration and login with passkeys has worked consistently. We receive ASAuthorizationError.Code.failed (1004): The authorization attempt failed. Do reviewers have special devices that do not support passkeys? What are some reasons that this code would fail? We've tested on the same device (iPads, iPhones, etc.) with different password managers and haven't run into this issue. We do not offer another sign in or registration for non-review users. We have a demo mode login provided to reviewers. Any help is appreciated, thanks.

Is there a way (in code or on the OAuth2 server/webpage) to specify the desired window size when using ASWebAuthenticationSession on macOS? I haven't found anything, and we would prefer the window to be narrower. For one of our users, the window is even stretched to the full screen width which looks completely broken…

hello, My organization has an outlook add-in that requires auth into our platform. As Microsoft forces Auth on MacOS to use WKWebView https://learn.microsoft.com/en-us/office/dev/add-ins/concepts/browsers-used-by-office-web-add-ins, we are running into a situation that we cannot use passkeys as an auth method as we are unable to trigger WebAuthN flows. We’ve raised this in Microsoft side but they have deferred to Apple given WKWebView is Safari based. This is a big blocker for us to achieve a full passwordless future. Has anyone come across this situation? Thank you.

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?

I have been implementing an sdk for authenticating a user. I have noticed that on iOS 18.5, whether using SFSafariViewController, or the sdk (built on ASWebAuthenticationSession), password autofill does not work. I have confirmed it works on a different device running iOS 18.0.1. Are there any work arounds for this at this time? Specifically for ASWebAuthenticationSession?

Problem Description: In our App, When we launch the web login part using ASWebAuthentication + Universal Links with callback scheme as "https", we are not receiving callback. Note: We are using "SwiftUIWebAuthentication" Swift Package Manager to display page in ASWebAuth. But when we use custom url scheme instead of Universal link, app able to receive call back every time. We use ".onOpenURL" to receive universal link callback scheme.

(related post: How to optimize my app for for a carrier-provided satellite network? ) I am trying to implement an app so that it works under a carrier-provided satellite network. The app uses (AS)WebAuthenticationSession for signing in. If the app is entitled to access a satellite network, will (AS)WebAuthenticationSession work as well? How about WKWebView and SFSafariViewController? Is there a way to test(simulate) a ultra-constrained network on a device or a simulator to see the expected behavior? Thanks,

(1) Context: Our project has a login feature via WEBVIEW (using SFSafariViewController) and integrates PassKey on the Web side. The app listens for a successful login by capturing the redirect URL via the delegate of SFSafariViewController. (2) Issue: On iOS < 18.4: The redirect URL is captured with full parameters returned. https://xyz.com/home?session_state=...&code=... On iOS ≥ 18.4: The redirect URL is captured successfully but missing parameters. https://xyz.com/home We currently suspect that the issue originates from the SFSafariViewController framework after the release of iOS 18.4. Has anyone experienced a similar issue? We would also appreciate support from the Apple team.

We’re exploring the use of Apple’s Automatic Assessment Configuration entitlement for an iOS app currently in the proof-of-concept stage. We’re enrolled in the Apple Developer Program with an active subscription. Both the Account Holder and team members have accepted all relevant license agreements. However, when we try to access the entitlement request form at: 👉 https://developer.apple.com/contact/request/automatic-assessment-configuration/ We are immediately redirected to: 🚫 https://developer.apple.com/unauthorized/ This happens for all team members, including the Account Holder, so it doesn’t appear to be a role-specific permissions issue. The app is still in the proof-of-concept stage — there’s no App Store listing or App ID yet. We’re trying to confirm entitlement eligibility before proceeding further. Questions: Is an App Store listing or App ID required to access this request form? Are there any hidden prerequisites (account permissions, team roles, prior submissions, etc.) that need to be fulfilled? Has anyone here successfully submitted this form — and if so, what steps or conditions were required? Any guidance or shared experience would be greatly appreciated. Thanks in advance!

we develop extension "Autofill Credential Provider" function for passkey. 1.first step registe passkey 2.second step authenticate with passkey step 1 & step 2 has finished and run success with provideCredentialWithoutUserInteraction. But we want to prepare our interface for use to input password and select passkey what the want. however the func prepareInterfaceToProvideCredential in ASCredentialProviderViewController does call? what i missed? how can i do it?

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,

override func prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest) int this function how can i get the "challenge" from user agent, the params "challenge" need to be used in webauthn navigator.credentials.create

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!

We're integrating Sign in with Apple into our iOS app The Apple ID login UI appears correctly on real devices, but after tapping Continue, the system immediately stops and shows code 1001. This issue happens across multiple devices and Apple ID accounts, even with no prior login history. We’ve confirmed the following Sign in with Apple is enabled in both Developer Portal and Xcode Capabilities Automatic signing and provisioning are set correctly Device is signed into iCloud and system time is synced Performed clean build, app reinstall, and other standard debugging steps We suspect that the sign in handshake process may not be completing properly due to some kind of account or server-side restriction, and we’d appreciate any insights into this behavior.