The High-Level Architecture of an Integrated Passkey Flow

1. Passkey Flow Architecture#

In this article we are going to walk through a high-level architecture of an integrated passkey flow using Corbado's passkey solution. Our goal is to outline the key components that are required of a passkey application, and how they work to create a seamless and secure authentication experience.

2. The 4 Actors in Corbado's Passkey Solution#

There are four actors involved when using Corbado's Passkey (Biometrics) Solution via API:

1. User: The end customer using a website, service or application
2. Your client: This is typically a graphical interface of the application
3. Your server: This is the backend and core logic of the application
4. Corbado: This is the service that Corbado provides for passkeys

3. The high-level architecture at a glance#

4. The 3 major components in Corbado's Passkey Solution#

There are three major components involved in Corbado's Passkey (Biometrics) Solution via API:

4.1 Authenticator Device#

A user is the end customer who wants to log in a website, service, orapplication. To do so, an person's account has to be authenticated whenaccessing a website or application first. Therefore, an authenticator device,e.g. a laptop, smartphone or tablet, will be used as a token to prove the legitimateaccess. The device has to provide a platform authenticator in this casea biometric scanning capability, e.g. iPhone with Face ID, Windows device withWindows Hello, MacBook with Touch ID or Android smartphone with fingerprintscanner and be FIDO2 or WebAuthn enabled. WebAuthn relies on public keyencryption, which means that during registration, authenticators will issuepublic keys to applications, while using the corresponding private key to signchallenges during authentication. Authenticators can take the form of eitherhardware or software. The device itself runs on a browser or native app and isused as an interface between the platform authenticator and the relying party.Via the WebAuthn API built-in platform authenticators (e.g. Face ID, WindowsHello) can be used.

4.2 Relying Party#

The website, service or application a user wants to access to is called the relying party. The relying party typically consists of a frontend and a backend: The client application is the user interface that allows your users to interact with your app. Its primary purpose in passkey applications is to facilitate authentication and registration processes. It typically is the graphical user interface of the application that calls the WebAuthn API on the browser/ app on the users device. The user's experience with the client may vary depending on the operating system and browser they use but should still offer the same level of security and usability, as long as the ecosystem supports passkeys. The backend of the relying party will facilitate the authentication and registration ceremonies in order to determine if the user should be allowed to access their requested resources.

4.3 Corbado API#

The backend of the relying party is in exchange with the Corbado API when integrating via REST API and not via web component. In this case, Corbado handles all the complexity of managing passkeys for your users, so that you can focus on your other features. This includes optimized passkey creation flows with post-sign-in nudges and intelligent passkey login flows that drive high adoption rates. However, Corbado does not take care of core user management (e.g. names, billing data, addresses). There is usually a separate user database at the relying party.

Frequently Asked Questions#

What are the main architectural components needed to implement a passkey authentication flow?#

A passkey flow requires three major components: an authenticator device with biometric capability, a relying party consisting of a frontend client and backend server, and a passkey service provider API. The authenticator device acts as the interface between the platform authenticator and the relying party, communicating through the WebAuthn API built into the browser or native app.

How does public key encryption work during WebAuthn passkey registration and login?#

During registration, the authenticator generates a key pair and sends the public key to the relying party application. During authentication, the authenticator uses the stored private key to sign a server-issued challenge, which the relying party verifies against the previously registered public key.

What does a passkey API provider handle versus what my own backend still needs to manage?#

A passkey API provider handles the complexity of passkey creation flows, login flows and adoption optimization so your team can focus on other features. Core user management data such as names, billing information and addresses is not covered and must be stored in a separate user database maintained by the relying party.

Which devices and operating systems are compatible with passkey authentication?#

Passkeys require a device with a platform authenticator that provides biometric scanning, such as an iPhone with Face ID, a Windows device with Windows Hello, a MacBook with Touch ID or an Android smartphone with a fingerprint scanner. The device must be FIDO2 or WebAuthn enabled and run on a compatible browser or native app.