通行密钥使用场景
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
借助通行密钥，您只需点按几下以及设备屏幕锁定，即可实现无需表单的登录体验。由于通行密钥包含用户的用户名和显示名称，因此浏览器或操作系统可以显示帐号选择器，供用户选择用于登录的帐号，然后解锁屏幕进行验证。通过放置“使用通行密钥登录”按钮，网站或应用可以让用户启动该流程。
对于确定只有通行密钥用户的 RP，建议采用这种用户体验。如果 RP 的用户没有通行密钥，他们仍然需要让用户通过表单等其他方法登录。对于这种情况，我们建议在表单字段中提供通行密钥自动填充建议。
通过简单的“使用通行密钥登录”按钮，即可提供基于通行密钥的身份验证。但是，如果某些用户有密码，RP 还必须为这些用户提供登录表单。为了支持这两种类型的用户，您可以改用用户名和密码表单，以便用户查看密码和通行密钥的自动填充建议（如果有）。这还可以让用户不必记住他们使用的是通行密钥还是密码。
使用此设置时，用户只要将光标放到表单字段上，就能看到帐号选择器。选择帐号时，如果帐号是基于密码的，则系统会自动填充用户名和密码字段。如果帐号基于通行密钥，它会立即要求用户解锁设备并尝试登录。
当 RP 正在从基于密码的身份验证或多重身份验证转换为使用通行密钥的无密码身份验证时，这种用户体验很合适。
了解如何打造这种用户体验：
重新验证
在用户已登录的情况下，重新验证是一种常见的用户体验，但由于会话已过期或用户即将执行敏感操作（例如添加送货地址或购物），需要进行额外的身份验证。
在基于密码的身份验证中，系统会要求用户输入密码进行重新身份验证，而使用通行密钥时，RP 只需要求解锁设备即可重新进行身份验证。
这种快速身份验证可确保同一用户仍位于设备前，从而更加安全继续操作。
了解如何打造这种用户体验：
使用手机登录
通行密钥会在属于同一生态系统的设备之间同步。例如，如果用户在 Android 设备上创建了通行密钥，只要该用户登录了同一个 Google 帐号，就可以在所有 Android 设备上使用通行密钥。但是，相同的通行密钥在 iOS、macOS 或 Windows 上不可用，即使您使用同一浏览器（例如 Chrome）也是如此。
只要手机靠近笔记本电脑且用户在手机上批准登录，用户就可以通过扫描二维码，使用手机上的通行密钥登录其他设备。这适用于不同的操作系统和浏览器。
假设某位用户有一部 Android 设备，并通过 Chrome 在网站上创建了一个通行密钥。通行密钥会保存并在 Android 设备之间同步，但不会在其他生态系统之间同步。当用户尝试在 macOS 13 Safari 上登录同一网站时，系统没有在 Mac 上保存通行密钥。用户仍然可以选择使用第二台设备上的通行密钥，使用 Android 设备登录。Safari 会显示一个二维码，用户可以使用 Android 手机扫描该二维码，然后选择通行密钥并使用其屏幕锁定功能进行验证。一次性通行密钥签名会传输回 Mac 上的 Safari，然后网站会使用该 Safari 让用户登录。这两个设备会使用蓝牙验证它们是否相距不远。
这种跨设备、跨操作系统的通行密钥身份验证机制在 FIDO 下进行了标准化，在 Chrome 和 Safari 中也可用，而其他浏览器也在遵循该机制。您无需执行任何额外的操作即可实现这种用户体验。当开发者遵循“使用通行密钥登录”按钮方法或上述通行密钥自动填充方法时，它会自动启用。
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2023-12-01。
[null,null,["最后更新时间 (UTC)：2023-12-01。"],[[["\u003cp\u003ePasskeys offer a passwordless sign-in experience using device screen lock for verification, simplifying user authentication.\u003c/p\u003e\n"],["\u003cp\u003eWebsites can implement passkey sign-in using a dedicated button or by integrating passkey autofill suggestions within existing forms.\u003c/p\u003e\n"],["\u003cp\u003ePasskeys enable reauthentication by simply unlocking the device, enhancing security and user experience.\u003c/p\u003e\n"],["\u003cp\u003eCross-device authentication is supported through QR code scanning, allowing users to sign in on one device using a passkey stored on another.\u003c/p\u003e\n"]]],[],null,["# Passkeys use cases\n\n\"Sign in with a passkey\" button\n-------------------------------\n\nPasskeys enable sign-in experiences without forms with just a few taps and the\ndevice screen lock. Because a passkey contains the user's username and display\nname, the browser or operating system can display an account selector for the\nuser to pick an account to sign-in with, then unlock the screen to verify. By\nplacing a \"Sign in with a passkey\" button, a website or application can let the\nuser initiate the flow. \n\nThis user experience is recommended for RPs that are certain they have only\npasskey users. If an RP has users without a passkey, they still need to let the\nusers sign in with other methods such as username and password with a form. For\nsuch cases, we recommend [Passkey autofill suggestions in form fields](#passkey-autofill-suggestions-in-form-fields).\n\nPasskey autofill suggestions in form fields\n-------------------------------------------\n\nPasskey-based authentication can be offered via a simple [\"Sign in with a\npasskey\" button](#sign-in-with-a-passkey-button). However, if there are some\nusers with passwords, the RP must offer a sign-in form for those users too. To\nsupport both types of users, a username and password form can be used instead\nwhich will allow the user to see autofill suggestions for both passwords and\npasskeys (if available). This also frees users from having to remember if they\nuse a passkey or password. \n\nWith this setup, a user sees an account selector as soon as they place a cursor\nto a form field. When selecting an account, if the account is password based, it\nautofills a username and password field. If the account is passkey based, it\nimmediately asks the user to unlock the device and attempts to sign them in.\n\nThis user experience is suitable when an RP is in transition from password-based\nor multifactor authentication to passwordless authentication using passkeys.\n\nLearn how to build this user experience:\n\n- [Sign in with a passkey through form\n autofill](https://web.dev/passkey-form-autofill)\n\nReauthentication\n----------------\n\nReauthentication is a common user experience when a user is already signed in,\nbut needs an additional authentication because a session has expired or because\nthe user is about to perform a sensitive operation, such as adding a shipping\naddress or making a purchase.\n\nIn password-based authentication, a user would be asked to enter their password\nto reauthenticate, but with passkeys, the RP can simply ask to unlock the device\nto reauthenticate. \n\nThis quick authentication ensures that the same user is still in front of the\ndevice so it's safer to proceed.\n\nLearn how to build this user experience:\n\n- [Build your first WebAuthn app](/codelabs/webauthn-reauth) (codelab)\n\nSign-in with a phone\n--------------------\n\nPasskeys are synchronized across devices that are part of the same ecosystem.\nFor example, if a user creates a passkey on Android, it's available on all\nAndroid devices as long as the user is signed in to the same Google account.\nHowever, the same passkey isn't available on iOS, macOS or Windows, even if\nyou're using the same browser, like Chrome.\n\nA user can use a passkey on their phone to sign in on other devices by scanning\na QR code, as long as the phone is near the laptop and the user approves the\nsign-in on the phone. This works across different operating systems and\nbrowsers.\n\nLet's say a user has an Android device and created a passkey on a website via\nChrome. The passkey is saved and synced among Android devices, but not other\necosystems. When the user tries to sign in to the same website on macOS 13\nSafari, there are no passkeys saved on the Mac. The user can still use the\nAndroid device to sign in by selecting to use a passkey from a second device.\nSafari shows a QR code that the user can scan using the Android phone, select\nthe passkey and verify with their screen lock. A one-time passkey signature is\ntransferred back to Safari on the Mac, which the website then uses to sign the\nuser in. The two devices verify that they are in proximity with each other using\nBluetooth. \n\nThis cross-device, cross-operating-system mechanism of passkey authentication is\nstandardized under FIDO and available in Chrome and Safari with other browsers\nto follow. There is no additional work needed to enable this user experience. It\nis automatically enabled when developers follow the \"Sign in with a\npasskey\"-button approach or the passkey-autofill approach outlined above."]]
