Passkey Javascript

[Lynne Pruskowski]

TheWeb Authentication API (WebAuthn) is an extension of the Credential Management API that enables strong authentication with public key cryptography, enabling passwordless authentication and secure multi-factor authentication (MFA) without SMS texts.

Note: Passkeys are a significant use case for web authentication; see Create a passkey for passwordless logins and Sign in with a passkey through form autofill for implementation details. See also Google Identity > Passwordless login with passkeys.

Many websites already have pages that allow users to register new accounts or sign into an existing account, and WebAuthn acts as a replacement or enhancement for the authentication part of the system. It extends the Credential Management API, abstracting communication between the user agent and an authenticator and providing the following new functionality:

In their most basic forms, both create() and get() receive a very large random number called the "challenge" from the server and return the challenge signed by the private key back to the server. This proves to the server that a user has the private key required for authentication without revealing any secrets over the network.

Note: The format for sharing information between the relying party server and the web app is up to the application. A recommended approach is to exchange JSON type representation objects for credentials and credential options. Convenience methods have been created in PublicKeyCredential for converting from the JSON representations to the form required by the authentication APIs: parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() and PublicKeyCredential.toJSON().

After a user has registered with WebAuthn, they can authenticate (i.e., login) with the service. The authentication flow looks similar to the registration flow, the main differences being that authentication:

Both directives have a default allowlist value of "self", meaning that by default these methods can be used in top-level document contexts. In addition, get() can be used in nested browsing contexts loaded from the same origin as the top-most document. get() and create() can be used in nested browsing contexts loaded from the different origins to the top-most document (i.e. in cross-origin ), if allowed by the publickey-credentials-get and publickey-credentials-create Permission-Policy directives, respectively. For cross-origin create() calls, where the permission was granted by allow= on an iframe, the frame must also have Transient activation.

Provides proof to a service that an authenticator has the necessary key pair to successfully handle an authentication request initiated by a CredentialsContainer.get() call. Available in the response property of the PublicKeyCredential instance obtained when the get() Promise fulfills.

The result of a WebAuthn credential registration (i.e., a CredentialsContainer.create() call). It contains information about the credential that the server needs to perform WebAuthn assertions, such as its credential ID and public key. Available in the response property of the PublicKeyCredential instance obtained when the create() Promise fulfills.

Provides information about a public key / private key pair, which is a credential for logging in to a service using an un-phishable and data-breach resistant asymmetric key pair instead of a password. Obtained when the Promise returned via a create() or get() call fulfills.

In their most basic forms, both create() and get() receive a very large random number called the \"challenge\" from the server and return the challenge signed by the private key back to the server. This proves to the server that a user has the private key required for authentication without revealing any secrets over the network.

\n Note: The format for sharing information between the relying party server and the web app is up to the application.\n A recommended approach is to exchange JSON type representation objects for credentials and credential options.\n Convenience methods have been created in PublicKeyCredential for converting from the JSON representations to the form required by the authentication APIs: parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() and PublicKeyCredential.toJSON().\n

\n Both directives have a default allowlist value of \"self\", meaning that by default these methods can be used in top-level document contexts.\n In addition, get() can be used in nested browsing contexts loaded from the same origin as the top-most document.\n get() and create() can be used in nested browsing contexts loaded from the different origins to the top-most document (i.e. in cross-origin ), if allowed by the publickey-credentials-get and publickey-credentials-create Permission-Policy directives, respectively.\n For cross-origin create() calls, where the permission was granted by allow= on an iframe, the frame must also have Transient activation.\n

Once an RP requests creating a passkey and the user verifies it with a screenunlock, a new passkey is created and a public key credential is returned. Sendthat to the server and store the credential ID and the public key for futureauthentication.

Once an RP requests an authentication with a passkey and the user verifies itwith a screen unlock, a public key credential is returned. Send that to theserver and verify the signature with the stored public key.

Upon creating a passkey, the server needs to provide key parameters such as achallenge, user information, credential IDs to exclude, and more. It thenverifies the created public key credential sent from the client and stores thepublic key in the database. For authenticating with a passkey, the server needsto carefully validate the credential and verify the signature to let the usersign in.

When you support passkeys on your existing service, the transition from theolder authentication mechanism such as passwords to passkeys won't happen in aday. We know you'd be inclined to eliminate the weaker authentication method assoon as possible, but that may cause user confusion or leave some users behind.We recommend keeping the existing authentication method for the time being.

Creating strong passwords and managing them for each website are challengingtasks for users. Using a password manager built into the system or a standaloneone is strongly recommended. By making a small tweak to the sign-in form,websites and apps can make a huge difference to its security and the sign-inexperience. Checkout how you can make those changes:

Though using a password manager helps users with handling passwords, not allusers use them. Asking for an additional credential called one-time password(OTP) is a common practice to protect such users. OTPs are typically providedthrough an email, an SMS message or an authenticator app such as GoogleAuthenticator.Because OTPs are usually a short text generated dynamically valid only for alimited time-range, it lowers the probability of account hijacks. These methodsare not as robust as a passkey, but much better than leaving users with just apassword.

Identity federation is another option to let users sign in securely and easily.With identity federation, websites and apps can let users sign in using theuser's identity from a third-party identity provider. For example, Sign in withGoogle delivers greatconversions for developers, and users find it easier and preferable to passwordbased authentication. Identity federation is complementary to passkeys. It'sgreat for signing up as the website or app can gain basic profile information ofthe user in a single step, while passkeys are great for streamliningreauthentication.

Keep in mind, after Chrome phases out third-party cookies in 2024, some identityfederation systems may be impacted depending on how they're built. To mitigatethe impact, a new browser API called Federated Credential Management API (FedCMin short) is being developed. If you run an identity provider, check out thedetailsand see if you'd need to adopt FedCM.

3a8082e126