在阅读了有关WebAuth API的大量文档后,我无法在iOS上成功启用平台身份验证。
我尝试将身份验证器附件设置为跨平台和平台,除了 iOS 之外,它们产生了一致的结果:
╭────────────────┬───────────────────────┬────────────────────────────┬────────────────────────────┬───────────────────────────────────────────────╮
│ Attachment │ Windows 10 │ Android 8 │ MacOS Catalina │ iOS 13 │
│ │ Edge/Chrome │ Chrome/Opera │ Chrome/Safari │ Webkit(Everything else is this anyways) │
╞════════════════╬═══════════════════════╬════════════════════════════╬════════════════════════════╬═══════════════════════════════════════════════╡
│ cross-platform ║ USB Key │ USB/Bluetooth Key │ USB/Bluetooth Key │ USB/Bluetooth Key │
│ platform ║ Fingerprint/Face/Pin │ Fingerprint/USB/Bluetooth │ Fingerprint │ "Insert security key" │
└────────────────┴───────────────────────┴────────────────────────────┴────────────────────────────┴───────────────────────────────────────────────┘
> 2020 年 10 月 19 日,苹果发布了他们对 WebAuthn 的看法的解释: https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/
从iOS 14和macOS Big Sur开始支持FaceID和TouchID。要使其正常工作,对于作为平台身份验证器的每个 allowCredentials 条目,您需要添加transport: ["internal"]
,否则它将继续提示输入 USB/NFC 令牌。
从本质上讲,这:
const publicKeyCredentialRequestOptions = {
challenge: challengeBuffer,
allowCredentials: [{
id: 'credentialsIdentifierOne', // Windows Hello
type: 'public-key'
}, {
id: 'credentialsIdentifierTwo', // iOS FaceID
type: 'public-key'
}],
timeout: 60000
}
变成这样:
const publicKeyCredentialRequestOptions = {
challenge: challengeBuffer,
allowCredentials: [{
id: 'credentialsIdentifierOne', // Windows Hello
type: 'public-key',
transports: ["internal"]
}, {
id: 'credentialsIdentifierTwo', // iOS FaceID
type: 'public-key',
transports: ["internal"]
}],
timeout: 60000
}
总体而言,这符合规范,您应该能够通过在AuthenticatorResponse
上调用.getTransports()
来检索身份验证器的传输列表。这在教程中没有广泛记录,甚至没有得到广泛的支持,所以要小心:
设置跨平台身份验证器时,返回的值通常仅包含使用的传输,而不是身份验证器支持的所有传输。例如,YubiKey 5 NFC仅在插入电源时使用时才返回["usb"]
。
因此,您应该避免同时为这些身份验证器设置transports
,或者将它们设置为所有"非内部"传输:["usb", "nfc", "ble"]
。
至于调用.getTransports()
,请检查它是否可用(2020 年 12 月,Safari 仍然没有(,如果不可用,则根据您请求平台身份验证器或跨平台身份验证器时回退到适当的transports
。
另一个非常重要的一点是:如果你启动SFSafariWebView在你的应用程序中处理这个问题,无论是PWA,Cordova还是本机,它都会意外失败。原因?苹果决定,在将FaceID作为选项提供给用户之前,需要用户激活(点击/点击(。更糟糕的是,您不知道身份验证肯定会失败 - iOS 使一切看起来都正常运行,甚至提示用户插入他们的身份验证器,同时知道不存在这样的身份验证器(凭据 ID 指向 iOS 知道的 FaceID(。
上述问题的解决方案是添加一个额外的步骤,并通过要求用户在调用WebAuthn代码之前按下按钮来中断身份验证流程。
不幸的是,iOS 上的支持目前仅限于外部身份验证器。对iOS的全面支持确实是阻止广泛采用的最后一件事,因此手指交叉iOS 14将提供所需的功能。
它在iOS 13.3发行说明中得到了简要提及:
https://developer.apple.com/documentation/ios_ipados_release_notes/ios_ipados_13_3_release_notes
预计到达时间,这将很快推出:
https://developer.apple.com/videos/play/wwdc2020/10670/
chrome 将不支持任何扩展名:
https://bugs.chromium.org/p/chromium/issues/detail?id=1097972
有请求 铬团队支持 iOS 13,14 的 WebAuth
https://bugs.chromium.org/p/chromium/issues/detail?id=1101804
对我来说,来自.Net的WebAuthn是一个完整的编码转换噩梦!然而,我终于让它工作了,但随后遇到了iOS问题。最后,一旦我弄清楚发生了什么,一旦我弄清楚发生了什么,Mac和iOS在设置身份验证器附件时都不喜欢它,我的修复程序很简单。因此,我最终不得不使用从这里获得的功能来检测操作系统:getOS((
然后我把它编码如下:
var os = getOS();
if (os == 'iOS' || os =='Mac OS') {
credentialOptions.authenticatorSelection.authenticatorAttachment = undefined;
}