To launch a Webauthn server, you will need the following components:
That’s a lot off classes! But don’t worry, as their configuration is the same for all your application, you just have to set them once. Let’s see all of these in the next sections.
The Public Key Credential Source Repository must implement Webauthn\PublicKeyCredentialSourceRepository
. It will retrieve the credential source and update them when needed.
You can implement the required methods the way you want: Doctrine ORM, file storage…
The token binding handler is a service that will verify if the token binding set in the device response corresponds to the one set in the request.
At the time of writing, we recommend to ignore this feature. Please refer to the dedicated page for more information.
Every Creation Responses contain an Attestation Statement. This attestation contains data regarding the authenticator depending on several factors such as its manufacturer and model, what you asked in the options, the capabilities of the browser or what the user allowed.
The user may refuse to send information about the security token for privacy reasons.Hereafter the types of attestations you may have:
The following attestation types are supported. Note that you should only use the none
one unless you have specific needs described in the dedicated page.
none
: no attestation is provided.
fido-u2f
: for non-FIDO2 compatible devices (old U2F security tokens).
packed
: generally used by authenticators with limited resources (e.g., secure elements). It uses a very compact but still extensible encoding method.
android key
: commonly used by old or disconnected Android devices.
android safety net
: for new Android devices like smartphones.
trusted platform module
: for devices with built-in security chips.
apple
: for Apple devices
This object will load the Attestation statements received from the devices. It will need the Attestation Statement Support Manager created above.
This object will load the Public Key using from the Attestation Object.
If you use extensions, you may need to check the value returned by the security devices. This behaviour is handled by an Extension Output Checker Manager.
You can add as many extension checkers as you want. Each extension checker must implement Webauthn\AuthenticationExtensions\ExtensionOutputChecker
and throw a Webauthn\AuthenticationExtensions\ExtensionOutputError
in case of an error.
More about that in this page.
The Webauthn data verification is based on cryptographic signatures and thus you need to provide cryptographic algorithms to perform those checks.
We recommend the use of the following algorithms to cover all types of Authenticators. Feel free to adapt this list depending on your needs.
This object is what you will directly use when receiving Attestation Responses (authenticator registration).
This object is what you will directly use when receiving Assertion Responses (user authentication).