密碼金鑰用途
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
設定密碼金鑰後，只要輕觸幾下就能登入，不必填寫表單，還可使用裝置螢幕鎖定功能。密碼金鑰含有使用者的使用者名稱和顯示名稱，因此瀏覽器或作業系統可以顯示帳戶選取器，讓使用者選擇要登入的帳戶，然後解鎖螢幕進行驗證。只要在網站或應用程式上加入「使用密碼金鑰登入」按鈕，即可讓使用者啟動流程。
如果 RP 只有密碼金鑰使用者，建議您提供這項使用者體驗。如果 RP 中的使用者沒有密碼金鑰，仍需讓使用者能夠以其他方式 (例如使用者名稱和密碼) 登入。針對這類情況，建議您在表單欄位中提供密碼金鑰自動填入建議。
您可以透過簡單的「使用密碼金鑰登入」按鈕提供密碼金鑰驗證功能。但是，如果部分使用者也使用密碼，RP 也必須為這些使用者提供登入表單。為了同時支援這兩種使用者，您可以改用使用者名稱和密碼表單，讓使用者能同時看到密碼和密碼金鑰的自動填入建議 (如有)。這樣一來，使用者就不必記住必須使用密碼金鑰或密碼。
完成這項設定後，使用者將滑鼠遊標移到表單欄位上時，就會看到帳戶選取器。選取帳戶時，如果帳戶採用密碼，則會自動填入使用者名稱和密碼欄位。如果帳戶採用密碼金鑰，系統會立即要求使用者解鎖裝置並嘗試登入。
當 RP 從密碼式/多重驗證轉換為使用密碼金鑰的無密碼驗證，會帶來這種使用者體驗。
瞭解如何打造這項使用者體驗：
重新驗證
重新驗證是常見的使用者體驗，當使用者已經登入，但因為工作階段已過期，或使用者即將執行敏感作業 (例如新增運送地址或進行購買交易)，因此需要進行其他驗證。
在密碼式驗證中，系統會要求使用者輸入密碼來重新驗證，不過有了密碼金鑰，RP 就可直接要求解鎖裝置來重新驗證。
這種快速驗證方式可確保同一位使用者仍在裝置前方，繼續進行操作更加安全。
瞭解如何打造這項使用者體驗：
使用手機登入
密碼金鑰會同步到屬於同一個生態系統的裝置。
舉例來說，如果使用者在 Android 中建立密碼金鑰，只要使用者登入相同的 Google 帳戶，就能在所有 Android 裝置上使用該密碼金鑰。不過，即便您使用的是相同的瀏覽器 (例如 Chrome)，iOS、macOS 或 Windows 也無法使用同一個密碼金鑰。
使用者只要掃描 QR code，就能用手機的密碼金鑰登入其他裝置，前提是手機靠近筆電，且使用者核准手機上的登入要求。這適用於不同的作業系統和瀏覽器。
假設使用者有 Android 裝置，並且透過 Chrome 在網站上建立密碼金鑰。密碼金鑰會儲存在 Android 裝置之間並保持同步，但不會同步到其他生態系統。使用者在 macOS 13 Safari 上嘗試登入相同網站時，Mac 上不會儲存任何密碼金鑰。使用者仍可透過另一部裝置選擇使用密碼金鑰，藉此使用 Android 裝置登入。Safari 會顯示 QR code，使用者可以使用 Android 手機掃描、選取密碼金鑰，並使用螢幕鎖定進行驗證。一次性密碼金鑰簽章會轉移回 Mac 的 Safari，網站會使用該金鑰讓使用者登入。這兩部裝置會透過藍牙驗證彼此是否鄰近。
這項跨裝置、跨裝置運作系統機制的密碼金鑰驗證機制已根據 FIDO 標準化，並可在 Chrome 和 Safari 中搭配其他瀏覽器使用。您不需要執行其他作業就能啟用這項使用者體驗。當開發人員按照「使用密碼金鑰登入」按鈕方法或上述密碼金鑰自動填入方法操作時，這項功能就會自動啟用。
除非另有註明，否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權，程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間：2023-12-01 (世界標準時間)。
[null,null,["上次更新時間：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."]]
