"Passkey "是FIDO多设备凭证的简称，这是一项新技术，可以方便地在多个设备上使用FIDO的防钓鱼认证方法和仪式。
我们相信，通行证提供了一种可行的、防钓鱼的密码替代品，特别是为消费类应用解决了终端用户的摩擦，我们致力于让开发者轻松地为其用户提供这种体验。密码锁也可能会给目前依赖FIDO平台认证器的解决方案带来挑战，这些解决方案通常是在劳动力和关键任务解决方案中实施的：作为一个行业，我们需要找到方法来收获这种新技术的优势，同时尽量减少其缺点。
起点:FIDO的平台认证器
密码是一个典型的例子，说明了人类文明有时会停留在局部的最大值上。至少从罗马时代开始，共享密码就被用来保护信息和资源，它直观、便携，而且（在天真的情况下）易于使用。
不幸的是，每个人都需要处理大量的账户来参与现代生活，这加剧了这种方法的缺点，包括密码可能被坏人远程和大规模窃取的所有方式。
FIDO联盟是一个由行业领导者组成的团体，它的成立是为了创造和促进采用抗网络钓鱼的技术，这可能是一个可行的密码替代品。如果你有兴趣深入了解FIDO，你可以收听我和Yubico的John Bradley就这个话题录制的《身份，解锁》播客节目。
就今天的故事而言，重要的一点是，FIDO2（该联盟制定的一套规范之一）导致了现代设备上抗网络钓鱼认证功能的普及。简而言之，这是通过描述认证器（物理密钥、设备上的安全硬件等）如何与浏览器对话，以及通过定义javascript API，使网站可以利用这些认证器来执行公钥密码学认证来实现的。
清晰如泥？在实践中：通过使用WebAuthn规范中定义的Javascript API，开发人员可以利用硬件密钥（如yubikeys）或设备上的安全硬件（如手机上的安全元件、笔记本电脑上的TPM），通过生物识别传感器来验证用户而不使用密码。这两种认证器类型分别被称为漫游认证器和平台认证器。
Auth0立即看到了这一举措的价值，并采用了Webauthn，既作为管理员访问我们管理仪表板的第二个因素，也作为开发人员在用Auth0保护他们的网络应用时可以用来验证他们的用户的方法。
去年，我有机会在Authenticate会议上介绍了我们观察到的采用数字。我们发现的趋势反映了整个行业的情况：大部分的采用似乎是在专业人员中，他们在访问他们管理的资源时需要高水平的保证，而消费者的采用则没有那么陡峭。
对这些结果有许多可能的解释，但共识是明确的：尽管在可用性方面取得了巨大的进步，硬件和软件也很普及，但这些方法对终端用户来说使用起来仍然很复杂。硬件钥匙是一种投资和麻烦，主要是保留给管理员和关键的知识工作者。平台认证器要好得多，但它们被捆绑在一个单一的设备上：而在商业场景中，这可能是一个令人垂涎的功能（例如，管理员喜欢知道请求来自一个被管理的设备），对于消费者场景，这在迁移到新设备、使用多个设备等方面带来挑战。重要的是，这也使Webauthn沦为第二个认证因素的角色：由于规格中缺乏可靠的恢复机制，至少需要提供另一种机制来访问自己的账户。而这种方法，大多数时候，最终是......密码。
密码
输入密码，或者如果你想用它们的学名来称呼它们，那就是多设备FIDO凭证。
密码锁旨在消除传统FIDO凭证或单设备凭证在可用性方面的缺陷。它们通过一个简单的技巧实现了这一点：它们允许FIDO凭证在多个设备上漫游。这一点同时解决了恢复问题（凭证现在有了备份，因此可以在其原始设备丢失后继续使用）和多次注册问题（不需要在每台设备上重复注册）。
你可以在多设备FIDO凭证登陆页面、介绍这一概念的白皮书中阅读更多信息，或者收听我与FIDO执行董事Andrew Shikiar和微软的Tim Cappalli就这一主题录制的《身份，解禁》播客节目--但这一想法的主旨确实如此简单。
注意：多设备FIDO凭证是FIDO的官方称谓，而供应商则将该技术称为 "通行证"--我非常喜欢这个术语（通行证，通行证钥匙，明白吗？
在这一点上，注册和登录的体验仍然在一定程度上取决于供应商，而美味的部分（漫游）发生在幕后，但只是为了让你尝尝：这里是在我们的早期演示位上的注册、登录和在不同设备上的登录是怎样的。你可以在文章后面找到完整的视频。
这里是一个测试的网络应用。
比方说，我们想注册；因此我们点击 "开立账户"。
你看到的是一个经典的注册页面，与你使用传统的用户名和密码或社交供应商注册时的体验相同。让我们在电子邮件地址中填入我们想要的注册值，然后点击 "继续"。
你在那里看到的提示是由身份提供者呈现的。该页面感觉到客户端设备具有通行证功能；因此，它提供了通过创建新通行证进行注册的选项。让我强调一下：你在这里看到的体验完全是由身份提供者控制的。
让我们选择 "继续使用通行证"。
现在，这个对话框确实来自平台供应商，在这种情况下，是苹果公司（我在装有MaOS Ventura和TouchID键盘的MacMini上用Safari浏览器运行这个演示）。该提示非常清楚。让我们触摸一下传感器，看看会发生什么。
在幕后，为这个身份提供者创建了一个新的密码。设备将负责存储它并开始漫游过程，而身份提供者将通过用户注册过程存储相应的公钥（更多细节见下一节）并开始一个会话。让我们签出并重新签入，以观察使用通行证的正常登录过程是怎样的。
现在设备已经有了这个域名的密码，只要我点击用户名字段，我就有机会（通过本地下拉/托架）使用它。我所需要做的就是把手指放在TouchID传感器上，然后我们就进去了。
这本身就很酷，但除了我们能够在没有任何额外恢复因素的情况下注册生物识别技术之外，并不是一个完全陌生的体验。是时候来点神奇的了!
如果我们拿起装有iOS16测试版的iPhone，我用同一个iCloud用户登录，我们用Safari浏览器导航到同一个网络应用......签入后，我们会看到以下屏幕。
和广告上说的一模一样!在Mac上创建的通行证漫游到了iPhone上，使我们有可能通过TouchID登录网络应用。令人难以置信的方便......和防钓鱼。
除了让你感受到基于密码的无缝体验之外，这个流程还展示了密码的一个关键特征：在这个时候，密码是要在它们所创建的供应商生态系统的边界内漫游。在这种情况下，一切都取决于我的iCloud用户：密码在我的苹果设备中漫游，类似于许多其他设置的情况：钥匙串、联系人、照片、受信任的WIFI网络、应用程序商店购买......而这确实是我们相信passkey能够在其他试图推翻密码的尝试失败后取得成功的原因之一，也是文章开头引用道德经的原因。
就像现代智能手机形式的具有公钥加密能力的硬件无处不在，使FIDO2有可能引入平台认证器一样，今天数据服务的广泛使用以及移动和浏览器平台内设置的漫游是通证的一个关键推动因素。漫游机制已经存在，它被广泛使用，而且供应商多年来一直在完善其安全性--只要想想过去几年中 "从旧到新的iPhone "的设置传输流程有多大的改进。而且从今天起，通行证只能在其生态系统内漫游。我在演示中创建的密码只能在我使用iCloud账户的苹果设备上使用。在文章后面的挑战部分有更多的想法。
然而，这并不意味着如果我使用多个供应商的设备，我就不能使用密码。今天我想谈谈passkey袖子里的最后一招，那就是使用passkey来进行跨设备认证仪式的能力。
你可以在这里看到官方FIDO演示中的操作流程，但你中敏锐的观察者可能已经注意到了网络应用中刚注册后的第一个签名的截图中的暗示。除了刚刚创建的passkey，victoria@somemail.com，你可能已经注意到一个标有 "来自附近设备的passkey... "的选项。我建议你看一下视频，了解一下这个体验是如何运作的，但总的来说。
- 如果你选择这个选项，网页会显示一个二维码
- 如果你有一台设备，而且你有你试图访问的应用程序的密码，无论该设备是否来自与请求设备不同的供应商，你都可以将其摄像头对准二维码并启动认证仪式。
- 两台设备进行蓝牙握手，以确保它们确实处于同一地理空间（并通过这样做来防止整个远程攻击），并在公共互联网上商定一个远程服务器，作为交换岗位。
- 拥有密码的设备被用来进行密码认证仪式；如果结果成功，第一台设备上的用户会发现他们在网络应用中签名。有点像带通行证的设备是一个无线安全钥匙。
- 在这一点上，建议应用程序的做法是提示用户是否要在他们当前的设备上创建一个新的密码。如果他们这样做了，他们现在就会有一个该应用的通行证，可以在原设备的供应商生态系统中漫游。比如说。如果你从Chromebook访问网络应用，而你的认证设备是iPhone，在流程开始时，你在苹果设备上只有一个网络应用的密码。在这里描述的流程结束时，你在苹果设备上仍然有一个网站的密码，同时在谷歌生态系统中也有一个新的网站密码。很方便!
你对这种体验感兴趣了吗？我敢打赌，你们中的许多人都是如此，并且表现出典型的行动偏向，使开发者在推动世界发展方面如此有效，你们想知道如何将所有这些提供给你们的用户。公平!让我们来看一看。
使用密码锁开发
假设你正在从头开始实施认证，而不是依赖一个服务。从实现的角度来看，密码锁看起来就像不提供证明声明的平台认证器（在下一节会有更多的介绍）。这意味着，从协议的角度来看，如果你的网络应用已经支持Webauthn，只要你不验证证明，你在技术上已经支持通配符。然而，从用户体验的角度来看，这可能并不完全正确。
- 你目前的注册页面中的提示和语言很可能是指与设备绑定的凭证（例如，"从这个设备上更快地登录"），这已经不是passkey的全部事实了
- 鉴于在passkey之前，你是直接负责账户恢复的，所以你有可能只使用平台认证器来启用第二个认证因素（关于这一点，下一节会有更多介绍）
- 本地平台使保存的密码可用的方式依赖于新的本地和浏览器API，在这一点上是特定于供应商的。
上述变化都不是特别难，特别是如果你已经实施了Webauthn，但你确实需要做一些工作来提供良好的体验。
在所有公开承诺实施多设备凭证的厂商中--苹果、谷歌和微软--苹果可能是走得最远的一个。他们在macOS和iOS的测试版中都提供了通行证支持，并在最近的开发者活动中投入了大量时间来探索他们在操作系统和Safari中添加的API，以允许应用和网站开发者在他们的体验中无缝集成通行证。这就是为什么我们在苹果硬件上做了所有的初步实验，如果你想深入了解细节，这可能也是你最好的选择。
不过，如果你想在你的应用程序中试验密码，你很快就会有一个更直接、更简单的途径。Auth0实验室，我们的研究和开发部门，正在努力将密码锁整合到Auth0提供的处理应用程序中的认证的选项中。在实践中，这意味着如果你将一个应用程序与Auth0集成，使用经典的协议，如OpenID Connect，你将能够在认证设置中翻转一个字面的开关，在你的应用程序使用的认证提示中启用通配符支持。如果你已经有一个应用被配置为使用Auth0进行认证，你就可以翻转开关，启用密码匙认证，而根本不需要触及你的代码。
如果你想看看该流程的运行情况，并观看前面用于描述主要通行证流程的截图序列的视频版本，请查看下面的演示：它在本周的开发者日主题演讲中出现。
这只是我们认为可以通过简单的、无代码的方式实现的通证场景的表面现象。然而，这个简单的演示应该足以让我们了解可以实现的目标，以及我们对促进采用这种新的有前途的技术的承诺。
挑战
在对passkey进行了这么多抒情之后，你会认为这个行业找到了它的圣杯......但可惜的是，完整的故事还有一些细微的差别。
如果以密码为起点，密码是一个明显的改进。他们使用的公钥加密技术和FIDO认证仪式使他们几乎无法伪造，而这是共享秘密的一个巨大优势。
然而，如果出发点是经典的FIDO2平台认证器，那么口令符确实放弃了一些良好的安全属性。虽然它有一些可用性方面的挑战，但一些管理员希望凭证被绑定到一个特定的设备上--也许是一个他们通过MDM控制的设备，并且对其符合安全策略有信心。同时，选择不使用通行证而继续使用经典的平台认证器可能并不容易。将通行证作为平台认证器来实施，使得支持通行证与现有的Webauthn实现成为可能，但这也意味着可能出现混乱--在某些情况下，是设计出来的。例如，苹果公司已经宣布，一旦passkey在发布的操作系统中得到支持，他们将不再允许创建设备绑定的密钥，例如，我们今天所知的平台认证器--一切都将是passkey（不包括漫游认证器，例如，硬件密钥，它们仍未被触及）。一想到高权限用户的重要凭证可能被备份到管理员不知道或无法控制的设备上，许多管理员就会夜不能寐。
还有其他方面也不可能让管理员非常高兴。例如，从今天起，通行证需要打开iCloud和同步才能发挥作用--这一政策目前在用于工作场所的设备中可能被禁用。或者说，密码可以通过AirDrop简单地共享给附近的设备。
这些决定中有许多是针对供应商的；因此它们不应该被看作是绝对不可避免的。例如，谷歌和微软是否也会将所有平台认证器整合为通行证，还有待观察。此外，FIDO的一些新功能将帮助网络应用确定传入的认证操作是否使用了可以漫游（"备份"）的凭证，以及它们是否已经被备份。所有这些功能都有望帮助设计政策执行者，协助管理员保留对他们所接受内容的控制权。
通行证的另一把双刃剑是账户恢复方面。事实上，通行证现在在一个供应商的同步设备组中漫游，并且对它们的访问被限定在相应的账户上（就像演示中我的iCloud账户、我的Mac和我的iPhone一样），这意味着对通行证集合的访问与对漫游功能所依赖的账户的访问一样安全。虽然消费者应用程序可能会非常高兴地把这个头痛的问题外包给苹果/谷歌/微软，但许多管理员可能对这种情况感到不舒服。再一次，我们需要等待所有相关的供应商发布他们的通行证实现，以了解真正的影响，以及将有哪些缓解措施。
最后：有些人对少数供应商，即操作系统和浏览器供应商，控制访问......嗯，所有东西的关键路径上的重要工件的想法感到不舒服，如果脱离密码的行动完全成功的话。对此没有一个简单的答案。有人可能会说，我们已经在这种情况下了，而这正是使passkey这样的东西可行的原因之一。我选择乐观：我希望，如果这项技术真的流行起来，将有办法堵住第三方供应商，总的来说，使生态系统更加公平和公正。再说一遍，现在是非常早期的阶段。
前进的道路
我们相信通行证为消费者应用提供了一个可行的密码替代方案，并且我们致力于促进这一急需的行业转变，使你、开发者和建设者能够轻松地为你的用户提供这种体验。
密码确实带来了新的挑战，特别是对于劳动力和关键任务解决方案、依赖FIDO平台认证器的应用（如其目前实施的那样）以及其他各种情况。不过，密码确实需要被淘汰：作为一个行业，我们需要找到方法来收获这项新技术的优势，同时尽量减少其缺点。
我们致力于做好我们的工作，既要及时提供最先进的、对开发者友好的功能，使密码成为可能，又要积极参与塑造这一技术未来的行业讨论。
这是一个激动人心的时代，对每个参与者来说都充满了潜力和希望。你会加入我们的旅程吗？
