Resources for passkeys in Apple’s iOS and iPadOS
Local Authenticator
(create and use passkeys from the local device)
External Authenticator
(create and use passkeys from another device)
The default platform authenticator in iOS 16+ and iPadOS 16+, Apple Passwords, has the following capabilities:
1 On iOS and iPadOS, user verification methods (device PIN, biometric, etc) must already be configured on the security key prior to credential creation
iOS and iPadOS support both client and authenticator roles for Cross-Device Authentication (CDA) .
iOS and iPadOS devices (as authenticators) do not support persistent linking for Cross-Device Authentication. When an authenticator is not persistently linked, a QR code must be scanned on every use.
WebAuthn credentials created using the platform authenticator in iOS/iPadOS 15 and earlier will not not be converted to passkeys but will remain available for the lifetime of the device.
To replace a legacy platform credential with a passkey, start a credential registration ceremony and pass the same user handle (user.id) in the request. iOS/iPadOS will overwrite the legacy credential with a new passkey that will be saved to Apple Passwords.
WKWebView is the embedded WebView (EWV) on iOS and iPadOS. Embedded WebViews allow the calling app full control over the embedded web session, including modifying and intercepting requests, so many web platform features are limited in these contexts.
NOTE:
Embedded WebViews run in the context of the calling app, meaning only passkeys for the linked web domain (RP ID) can be created or used for sign in.
Said differently, only use EWV when sign in is handled by your own service (non-federated). When supporting multiple identity providers, System WebView should be used (see below).
WKWebView docs @ Apple Developer
ASWebAuthenticationSession is the System WebView (SWV) on iOS and iPadOS for authentication flows. All Web Platform features that are available in Safari, including WebAuthn, are available in a ASWebAuthenticationSession instance.
Sites loaded in ASWebAuthenticationSession are isolated from the calling app and run in the context of the top level site, just like in a full browser. This means that sign in flows on third party domains, such as a federated identity provider, can use passkeys for signing in.
ASWebAuthenticationSession docs @ Apple Developer
When a user tries to interact with a passkey on iOS or iPadOS, an available screen unlock method is used for user verification. Users can configure a passcode and Touch ID or Face ID as their screen unlock.
Both passkey creation and authentication ask for Touch ID or Face ID if one is configured, but fallback to a passcode if they are not. iOS asks the user to configure a passcode (and Touch ID or Face ID) if not yet set up.
userVerification='required' and userVerification='preferred' are the same: iOS asks for tapping on a “Confirmation” button, then a passcode for both passkey creation and authentication. Since they fail locally if user verification fails, the server can always expect the UV flag to be true.PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() always returns true.userVerification='required' and userVerification='preferred' are the same: User verification fails, iOS asks the user to set up a passcode and then Touch ID or Face ID for both passkey creation and authentication. Since the failure happens locally, the server can expect at least a passcode is already configured and the UV flag to be true.PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() always returns true.此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。