The High-Level Architecture of an Integrated Passkey Flow

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.

The 4 Actors in Corbados 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

The high-level architecture at a glance

The 3 major components in Corbados Passkey Solution

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

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.

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.

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. 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.