Begin your journey to implement a backend application that supports passkeys
In this guide we are going to discuss how to build a backend application that supports passkeys. This guide will encompass a variety of topics, examples, and best practices that are supported by Yubico’s extensive experience in building and advising on WebAuthn applications. At the end of this guide you should possess the knowledge and foundational understanding required to build a passkey supported application.
A relying party is an industry term that is used to describe an application that is used to verify the identity of an entity through authentication, and to provide the correct level of authorization based on the permissions granted to the entity.
In terms of passkey applications, this is the component that will manage credentials, verify and issue authentication challenges, and grant access when appropriate. While relying parties for passkey applications facilitate similar ceremonies, they are not one size fits all, and should reflect the security policies set by business or regulatory requirements. In this guide when we refer to the backend application, note that we are only referencing the responsibilities of the relying party.
The application layer will be responsible for the core business logic required to complete registration, authentication, and user/credential management operations. This component will primarily be invoked by API’s for specific actions. The primary goal will be to issue registration and authentication ceremonies, using inputs from the identity provider, and by referencing credentials stored in the credential repository.
This is the service that will allow your application to manage users, and issue authorization tokens (such as OAuth2) to access its resources. This can be a custom built solution, or a solution purchased from a technology vendor.
As this guide is primarily for those looking to build a passkey relying party, our focus will be on custom built solutions.
This is the repository of user passkeys that were sent to the relying party during registration, and leveraged during the authentication ceremony. An advantage of using passkeys rather than passwords is the severity of this repository being compromised is lowered. This repository can operate by only storing the public key, credential IDs, and associated user handle. If this repository is leaked, an attacker cannot leverage the public keys, without access to the authenticator with the private key.
This is an optional component of your relying party, but should be included as a best practice. A metadata repository will allow your application to identify the make and model of a registered authenticator, if permission was granted by the user during registration.
On the surface level this data can help the user experience by helping users and administrators understand more details about their authenticator. Digging deeper, this repository can help you impose different degrees of authenticator management, in high assurance scenarios that require some control over what can and cannot register in your environment. More will be covered on this when we discuss attestation.
If you are ready to begin, please click the link below to continue. We will begin by discussing prerequisites to help you get started in developing a relying party.