패스키를 사용하면 탭 몇 번이나 기기 화면 잠금만으로 양식 없이도 로그인할 수 있습니다. 패스키에는 사용자의 사용자 이름과 표시 이름이 포함되므로 브라우저 또는 운영체제에서 사용자가 로그인할 계정을 선택하고 화면 잠금을 해제하여 확인할 수 있도록 계정 선택기를 표시할 수 있습니다. '패스키로 로그인' 버튼을 배치하면 웹사이트나 애플리케이션에서 사용자가 흐름을 시작하도록 허용할 수 있습니다.
이 사용자 환경은 패스키 사용자만 있는 RP에 권장됩니다. RP에 패스키가 없는 사용자가 있는 경우에도 사용자가 양식을 통해 사용자 이름과 비밀번호와 같은 다른 방법으로 로그인하도록 허용해야 합니다. 이러한 경우 양식 입력란의 패스키 자동 완성 추천을 사용하는 것이 좋습니다.
양식 입력란의 패스키 자동 완성 추천
간단한 '패스키로 로그인' 버튼을 통해 패스키 기반 인증을 제공할 수 있습니다. 하지만 비밀번호가 있는 사용자가 있는 경우 RP는 해당 사용자에게도 로그인 양식을 제공해야 합니다. 두 유형의 사용자를 모두 지원하기 위해 사용자 이름과 비밀번호 양식을 대신 사용하면 사용자가 비밀번호와 패스키 모두에 관한 자동 완성 추천 (사용 가능한 경우)을 볼 수 있습니다. 이렇게 하면 사용자가 패스키 또는 비밀번호를 사용했는지 기억하지 않아도 됩니다.
이 설정을 사용하면 사용자가 양식 입력란에 커서를 놓는 즉시 계정 선택기가 표시됩니다. 계정을 선택할 때 계정이 비밀번호 기반이면 사용자 이름 및 비밀번호 필드가 자동 완성됩니다. 계정이 패스키 기반인 경우 사용자에게 즉시 기기를 잠금 해제하도록 요청하고 로그인을 시도합니다.
이 사용자 환경은 RP가 비밀번호 기반 또는 다중 인증(MFA)에서 패스키를 사용한 비밀번호 없는 인증으로 전환 중인 경우에 적합합니다.
패스키는 동일한 생태계에 속한 기기 간에 동기화됩니다.
예를 들어 사용자가 Android에서 패스키를 만들면 동일한 Google 계정에 로그인되어 있는 한 모든 Android 기기에서 패스키를 사용할 수 있습니다.
그러나 Chrome과 같은 동일한 브라우저를 사용하더라도 iOS, macOS, Windows에서는 동일한 패스키를 사용할 수 없습니다.
휴대전화가 노트북 근처에 있고 사용자가 휴대전화에서 로그인을 승인한 경우 사용자는 휴대전화의 패스키를 사용하여 QR 코드를 스캔하여 다른 기기에 로그인할 수 있습니다. 이 기능은 다양한 운영 체제와 브라우저에서 작동합니다.
사용자가 Android 기기를 가지고 있고 Chrome을 통해 웹사이트에 패스키를 만들었다고 가정해 보겠습니다. 패스키는 Android 기기 간에 저장되고 동기화되지만 다른 생태계에서는 동기화되지 않습니다. 사용자가 macOS 13 Safari에서 동일한 웹사이트에 로그인하려고 하면 Mac에 저장된 패스키가 없습니다. 사용자는 다른 기기에서 패스키를 사용하도록 선택하여 Android 기기를 사용하여 로그인할 수 있습니다.
Safari에서 사용자가 Android 휴대전화를 사용하여 스캔할 수 있는 QR 코드를 표시하고 패스키를 선택한 다음 화면 잠금으로 인증합니다. 일회성 패스키 서명은 Mac의 Safari로 다시 전송되고, 이후 웹사이트에서는 이를 사용하여 사용자를 로그인 처리합니다. 두 기기는 블루투스를 사용하여 서로 가까이 있는지 확인합니다.
이 패스키 인증의 교차 기기, 교차 운영체제 메커니즘은 FIDO로 표준화되었으며 Chrome 및 Safari에서 이후 다른 브라우저와 함께 사용할 수 있습니다. 이 사용자 환경을 사용 설정하기 위해 추가 작업이 필요하지는 않습니다. 이 기능은 개발자가 위에서 설명한 '패스키로 로그인' 버튼 방식 또는 패스키 자동 완성 방식을 따를 때 자동으로 사용 설정됩니다.
[[["이해하기 쉬움","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(UTC)"],[[["\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."]]
