Deprecation from U2F API to WebAuthn

If you’re using the U2F API for registration and authentication of your U2F devices, you will notice a dire situation is coming soon: Google Chrome will no longer support U2F API after February: For anyone using U2F API in their web apps, like us at Sentry, their users who had 2FA enabled with U2F devices would not be able to sign in. To remedy this, there’s a shiny new specification written by the World Wide Web Consortium (W3C) and the Fast IDentity Online Alliance (FIDO) that will solve all our problems. In this blog post, we will go into the weeds on migrating from U2F API to WebAuthn.

WebAuthn

WebAuthn is an API that allows web services to seamlessly integrate strong authentication into applications.

Richard Ma

Richard is a software engineer at Sentry and a collector of cool clothing.

With WebAuthn, web services can offer the user a choice of authenticators, such as security keys (Yubikeys, Titan Keys, for example) or built-in platform authenticators (biometric readers). In addition, it is supported by all the leading browsers — including Safari, which U2F API was not — and web platforms, which standardizes the integration of strong authentication. You can read more on WebAuthn’s website.

Migrating to WebAuthn from U2F API

Now, here’s the part you’re all here for, the migration to WebAuthn. Let’s break this down into two main parts:

• Part 1: Authenticating existing U2F and new WebAuthn devices with WebAuthn
  • Step 1: Generating the challenge and state
  • Step 2: Creating PublicKeyCredential data
  • Step 3: Verifying the device

• Part 2: Registering new devices with WebAuthn
  • Step 1: Generating the challenge and state
  • Step 2: Creating PublicKeyCredential data
  • Step 3: Registering the device

Part 1: Authentication

Let’s start with authentication so existing users can continue to log in. This is also important because newly registered WebAuthn devices can’t log in without a working WebAuthn login. To understand the authentication flow, we can look at the following diagrams: We’ll be using Python for the backend APIs. The U2F API sequence (left) is very similar to the WebAuthn sequence (on the right). We simply have to replace three API calls: u2f.start_authentication() and u2f.finish_authentication() in the backend, and u2f.sign() in the frontend. Let’s start with u2f.start_authentication(), which takes in the browser’s application ID and the currently registered devices. The U2F API authentication process starts with the backend generating a challenge, an example of which is shown below: This challenge is sent to the browser where u2f.sign() takes the challenge as an input and returns a promise that is the result of:

• verifying the application identity of the caller
• creating a client data object and using the client data
• the application ID
• the key handle

This creates a raw authentication request message and sends it to the U2F device. The result of the promise should look like this: Once the result of the promise is sent to the server, we call U2f.complete_authentication() with the following two parameters: the original challenge data and the newly generated client data object passed in. This method will verify the device with the parameters and return the device info if it succeeded. From there, the server can allow the user to pass through the 2FA process.

Step 1: Generating the Challenge and State

To start the migration process, let’s first replace u2f.start_authentication() with its counterpart. The data types that the WebAuthn API takes are not quite the same ones used in U2F API. In fact, one of the main pain points was converting the necessary fields into the correct data type. We want to authenticate users on legacy U2F API and WebAuthn, so we will create an authentication server first. The following will create an authentication server using WebAuthn that is backward compatible with U2F API: Your app_id will be the same value as before. The rp, or Relying Party, is an object that contains an ID, which is the hostname of the URL, and the name of your Relying Party. Next, we need to generate a list of credentials, which is the same as the list of devices for U2F API. Keep in mind that the list of credentials will contain both WebAuthn and U2F API registered devices and that list needs to be manipulated. The devices that are registered with WebAuthn have the type AuthenticatorData. For devices registered with U2F API, we need to create an AttestedCredentialData object for them to be compatible with WebAuthn. The following is the function we wrote that decodes the necessary parameters and creates the credential data: Source of function  With that, we can begin the registration process by calling register_begin() on the WebAuthn server that we created earlier, with credentials as its parameter. This will return a challenge and state. The challenge is needed for the browser to perform authentication, but we will only use the PublicKey object within the challenge. In addition, you should store the state in your sessions, as it will be needed later. We also encoded the challenge using the FIDO2 CBOR library, as we will be sending it to the frontend using JSON, which does not handle binary representation well on its own. On the frontend, we convert the JSON string back into a byte array and decode it to return the challenge to its original form.

Step 2: Generating PublicKeyCredential for Authentication

To replaceu2f.sign(), we can call its WebAuthn equivalent navigator.credentials.get() with the challenge data. This library is now native to modern browsers, so don’t worry about importing any libraries. When the promise is resolved after calling navigator.credentials.get(), we need to send the appropriate data to the backend to finish authentication. To convert the PublicKeyCredential that was obtained from navigator.credentials.get(), we can run it through the following function:

Step 3: Verifying the Device

For the final step, we can pass the original challenge and this new response to the backend. We need to create a list of credentials to validate the device, then call authenticate_complete on the authentication server that was made earlier with the following parameters:

• • state: the value which we stored in session from start_authentication
  • credentials: list which we just generated
  • A websafe_decode for the following:

• • • credential_id: a “keyHandle” of the response object
    • client_data: a “clientData” of the response object passed through fido2.client.ClientData
    • auth_data: an “authenticatorData” of the response object passed through fido2.ctap2.authenticatorData
    • signature: a “signatureData” of the response object

If this function returns true, you are now fully authenticated and good to go! For our deployment, this feature was behind a flag to manage the rollout and for error monitoring. (We recommend using Sentry 😉.) We deployed this feature independently from registration because the area of effect is limited in the event of an incident. Congrats! The authentication part of the migration is finished.

Part 2: Registration

Similar to authentication, first, let’s take a look at the flow: The flow of registration is almost identical to that of the authentication process. The three components we need to deprecate in order to migrate to WebAuthn are u2f.begin_registration() and u2f.complete_registration() in the backend, and u2f.register() in the frontend. Once again, we will start with u2f.begin_registration(). This API call takes in the u2f application ID and list of registered devices. This results in the following data being sent to the browser to begin the registration process: Similar to u2f.sign(), u2f.register() will take the previously generated results and return a promise that will look like the following if the device is registrable: Along with the previously generated challenge, this result is sent to the backend where u2f.complete_registration() takes in both parameters and generates the following data object: You can save this dictionary and name of the device. They will be used for authentication. Just like before, let’s replace u2f.begin_registration()with its counterpart. We need to create a FIDO2Server and import it from fido2.server. We don’t need to make it backward compatible, as all new devices will be registered with WebAuthn.

Step 1: Generating the PublicKeyCredentialRpEntity and State

We start with importing the fido2.webauthn library to create a PublicKeyCredentialRpEntity. To create the entity, we need to pass in the Relying Party’s ID and name. With the entity, we pass it into Fido2Server to set things up. When the server is created, we can optionally pass in a list of registered devices to avoid duplicate registrations. Next, we call register_begin() with: user: dictionary with the user’s id, name, and display name credentials: the list we just generated user_verification: normally defaulted to discouraged You should get a result similar to this: The registration data as seen above will be returned. Encode the registration data with the cbor.encode() method and base64 encode that to a string. Set the state for later use in the session. Interestingly, the data from WebAuthn is exactly the same as from U2F API, despite looking different at first glance. WebAuthn sets the challenge in a byte array and the clientData in a COSE key object (which is a CBOR map), while U2F API uses an encoded string.

Step 2: Generating PublicKeyCredential for Registration

Once the registration data is received by the browser, we convert the string into a buffer and decode it with this library. This gives us the data that will be used as the input parameter of navigator.credentials.create(): When the promise from navigator.credentials.create() is resolved, we need to run it through getU2FResponse() before returning it to the server again.

Step 3: Registering the Device

We have reached the final step where we need to extract some data from the response from navigator.credentials.create(). The following are needed for register_complete():

• state: from user sessions, set earlier after begin_registration()

• client_data: from decoding the data’s cliendDataJSON and creating a ClientData Object with it.

• AttestationObject: from decoding the data’s attestationObject and creating an AttestationObject Object with it.

ClientData should look like this: AttestationObject should look like this: Registered device data: With that, you can save the registered device data. The registration process is complete. Just like authentication, the deployment of this feature was behind a feature flag to manage the rollout. There were no database migrations needed as WebAuthn is backward compatible with U2F API.

That’s a Wrap

With that, WebAuthn should be set up and you can purge U2F API from your codebase. If you have made it this far, we hope that this guide was useful to you. With some planning, you will make it in time before Chrome locks out users from your application. All the best! Everything we do at Sentry is built in the open. Find us on GitHub.