Prerequisites to begin implementing a passkey relying party
In this section we are going to discuss some common requirements that are needed in order to begin building a relying party. We will highlight the specific technologies that are used through this guide, as well as providing alternatives if required.
We’ll begin by addressing the application layer. You don’t need to build all of the functionality required to read, parse, and process passkey related data. There are a number of prebuilt libraries that can help facilitate these transactions, and we highly recommend that you leverage one of them.
In this guide we will be utilizing Yubico’s java-webauthn-server library.
If you are not familiar with Java, or wish to utilize another library, webauthn.io has a collection of libraries in a variety of programming languages.
Another aspect that you should consider is around where your application will be deployed (infrastructure) and how it will be accessed (API).
In this guide we will be using AWS Lambda and AWS API Gateway as our application’s infrastructure.
Next is the service that is going to be used to manage user profiles, and to issue authorization tokens if the user successfully passes the authentication checks. Similar to the application layer, you don’t need to fully build the functionality by scratch; you can leverage a pre-built service that allows for custom authentication flows, that can trigger the business logic in your application layer.
In this guide we will be utilizing a custom flow in AWS Cognito.
This is the component that will store and manage user credentials, and will be referenced whenever a user attempts to authenticate with their passkey. Two things need to be considered for your credential repository: the database that will be used, and how your application layer communicates with it.
The java-webauthn-server library has an interface that can be used to create a custom class that you can customize to interact with your selected datasource. These interactions will need to utilize the API’s provided by your chosen database; so while we demonstrate code samples using the interface, the core logic will be out of scope of this guide.
In terms of storing credentials, we will be utilizing an AWS Aurora database.
|
Note
|
You will need a repository to store registration and authentication requests. You are free to utilize the same database provider as above, but note that each will require a separate table with its own fields |
Lastly we will need a repository that contains metadata of different passkey and WebAuthn authenticators. This will be used to identify the make and model of an authenticator that was utilized during the registration ceremony. This component is primarily used for high assurance applications, but still has some nice user experience benefits for low assurance scenarios.
We will be using the FIDO Metadata Service for this repository
The java-webauthn-server library has built-in functionality to support connections to the BLOB containing the FIDO metadata service.
Now that we have the foundational components in place, let’s initialize our new passkey application.