[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：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."]]
