You can indicate the user verification requirements during the ceremonies by setting the value in your options.

The following example is totally fictive. We will add an extension input loc=true to the request option object.

An Extension Output Checker (EOC) will check the extension output.

It must implement the interface Webauthn\AuthenticationExtensions\ExtensionOutputChecker and throw an exception of type Webauthn\AuthenticationExtension\ExtensionOutputError in case of error.

In the previous example, we asked for the location of the device and we expect to receive geolocation data in the extension output.

You can create as many EOC as needed. These services can be managed by a handler that will be injected to the Ceremony Step Manager Factory. Extensions will be automatically verified during the validation steps.

During this step, your application will send a challenge to the list of registered devices of the user. The security token will resolve this challenge by adding information and digitally signing the data.

Assertion Request

To perform a user authentication using a security device, you need to instantiate a Webauthn\PublicKeyCredentialRequestOptions object.

Let’s say you want to authenticate the user we used earlier. This options object will need:

• A challenge (random binary string)

• The list with the allowed credentials (may be an option in certain circumstances)

Optionally, you can customize the following parameters:

• A timeout

• The Relying Party ID i.e. your application domain

• The user verification requirement

• Extensions

The PublicKeyCredentialRequestOptions object is designed to be easily serialized into a JSON object. This will ease the integration into an HTML page or through an API endpoint.

The user trying to authenticate must have registered at least one device. For this user, you have to get all Webauthn\PublicKeyCredentialDescriptor associated to his account.

Eligible authenticators are filtered and only capable of satisfying this requirement will interact with the user. Please refer to the for all possible values.

Please refer to the to know how to manage authentication extensions.

The way you receive this response is out of scope of this library. In the previous example, the data is part of the query string, but it can be done through a POST request body or a request header.

What you receive must be a JSON object that looks like as follows:

There are two steps to perform with this object:

This step is exactly the same as the one described in process.

Now we have a fully loaded Public Key Credential object, but we need now to make sure that:

1. The authenticator response is of type AuthenticatorAssertionResponse

2. This response is valid.

The first is easy to perform:

The second step is the verification against the Public Key Assertion Options we created earlier.

The Authenticator Assertion Response Validator service (variable $authenticatorAssertionResponseValidator) will check everything for you.

If no exception is thrown, the response is valid and you can continue the authentication of the user.

Attestation Statement Support Manager

There are few steps to acheive. First, you have to add support classes for all attestation statement types into your Attestation Metatdata Manager.

<?php

declare(strict_types=1);

use Cose\Algorithm\Manager;
use Cose\Algorithm\Signature\ECDSA;
use Cose\Algorithm\Signature\EdDSA;
use Cose\Algorithm\Signature\RSA;
use Webauthn\AttestationStatement\AndroidKeyAttestationStatementSupport;
use Webauthn\AttestationStatement\AttestationStatementSupportManager;
use Webauthn\AttestationStatement\FidoU2FAttestationStatementSupport;
use Webauthn\AttestationStatement\NoneAttestationStatementSupport;
use Webauthn\AttestationStatement\PackedAttestationStatementSupport;
use Webauthn\AttestationStatement\TPMAttestationStatementSupport;
use Webauthn\AttestationStatement\AppleAttestationStatementSupport;
use Symfony\Component\Clock\NativeClock;

//We need a PSR-20 clock
$clock = new NativeClock();

// You normally already do this
$attestationStatementSupportManager = AttestationStatementSupportManager::create();
$attestationStatementSupportManager->add(NoneAttestationStatementSupport::create());

// Additional classes to add
$attestationStatementSupportManager->add(FidoU2FAttestationStatementSupport::create());
$attestationStatementSupportManager->add(AppleAttestationStatementSupport::create());

$attestationStatementSupportManager->add(AndroidKeyAttestationStatementSupport::create());
$attestationStatementSupportManager->add(TPMAttestationStatementSupport::create($clock));

// Cose Algorithm Manager
// The list of algorithm depends on the algorithm list you defined in your options
// You should use at least ES256 and RS256 algorithms that are widely used.
$coseAlgorithmManager = Manager::create();
$coseAlgorithmManager->add(ECDSA\ES256::create());
$coseAlgorithmManager->add(RSA\RS256::create());

$attestationStatementSupportManager->add(PackedAttestationStatementSupport::create($coseAlgorithmManager));

Metadata Statement Repository

Then, you must prepare an Metadata Statement Repository. This service will manage all Metadata Statements depending on their sources (local storage or distant service).

Your Metadata Statement Repository must implement the interface Webauthn\MetadataService\MetadataStatementRepository that has only one method:

• findOneByAAGUID(string $aaguid): this method retrieves the MetadataStatement object with AAGUID. It shall return null in case of the absence of the MDS.

To prevent the use of rogue MDS or deprecated by the manufacturers, Status Reports may be used. The Status Report Repository is a simple service that implements the interface Webauthn\MetadataService\StatusReportRepository with a unique method:

• findStatusReportsByAAGUID(string $aaguid): this method returns a list of Status Reports for the given AAGUID.

The verification's success or failure depends on the state reported in the most recent Status Report.

When an attestation statement is received, a certificate chain is constructed. This chain combines certificates from the Metadata Service (MDS), which are trusted, with those provided by the authenticator, which are untrusted.

The Certificate Chain Validator is responsible for this task. The library provides the class Webauthn\MetadataService\CertificateChain\PhpCertificateChainValidator that requires a Symfony Http Client () and a PSR-20 Clock.

The services described above must be set to the . The CSM you will create will verifiy the attestation statement sent by the authenticator.

By default, no Attestation Statement is asked to the Authenticators (type = none). To change this behavior, you just have to set the corresponding parameter in the Webauthn\PublicKeyCredentialCreationOptions object.

There are 3 conveyance modes available using PHP constants provided by the class Webauthn\PublicKeyCredentialCreationOptions:

• ATTESTATION_CONVEYANCE_PREFERENCE_NONE: the Relying Party is not interested in authenticator attestation (default)

• ATTESTATION_CONVEYANCE_PREFERENCE_INDIRECT: the Relying Party prefers an attestation conveyance yielding verifiable attestation statements, but allows the client to decide how to obtain such attestation statements.

• ATTESTATION_CONVEYANCE_PREFERENCE_DIRECT

Welcome to WebAuthn, the solution for strong authentication on the web. With WebAuthn, you can offer your users a secure, simple, and convenient authentication experience that seamlessly integrates with your PHP or Symfony application.

At Spomky-Labs, we are committed to making the web safer for all users. We provide free, libre, and open-source libraries and a Symfony bundle to help you implement strong authentication solutions for your websites and applications.

WebAuthn is an open-source technology developed by the World Wide Web Consortium (W3C) and is compatible with all modern web browsers. With WebAuthn and PHP, you can offer your users secure authentication without requiring them to remember complex passwords or provide sensitive personal information.

WebAuthn is supported by the FIDO Alliance, an organization working to promote open and interoperable strong authentication standards. You can learn more about the FIDO Alliance by visiting their website at https://fidoalliance.org/.

Explore our documentation to learn more about WebAuthn and how it can help you implement strong authentication in your PHP or Symfony application.

This framework contains several sub-packages that you don’t necessarily need. It is highly recommended to install what you need and not the whole framework.

The preferred way to install the library you need is to use composer:

composer require web-auth/webauthn-lib

If you use Symfony Framework, you may be interested in the bundle and, optionally, the Stimulus component.

composer require web-auth/webauthn-symfony-bundle web-auth/webauthn-stimulus

Hereafter the dependency tree:

• web-auth/webauthn-lib: this is the core library. This package can be used in any PHP project or within any popular framework (Laravel, CakePHP…)

• web-auth/webauthn-symfony-bundle: this is a Symfony bundle that ease the integration of this authentication mechanism in your Symfony project.

The core library also depends on web-auth/cose-lib and web-auth/metadata-service. What are these dependencies?

web-auth/cose-lib contains several cipher algorithms and COSE key support to verify the digital signatures sent by the authenticators during the creation and authentication ceremonies. These algorithms are compliant with the . This library can be used by any other PHP projects. At the moment only signature algorithms are available, but it is planned to add encryption algorithms.

web-auth/metadata-service provides classes to support the . If you plan to use Attestation Statements during the creation ceremony, this service is mandatory. Please note that Attestation Statements decreases the user privacy as they may leak data that allow to identify a specific user. The use of Attestation Statements and this service are generally not recommended unless you REALLY need this information. This library can also be used by any other PHP projects.

The mechanism for generating public key credentials, as well as requesting and generating Authentication assertions, can be extended to suit particular use cases. Each case is addressed by defining a registration extension.

Standard extensions are usually listed in the dedicated IANA Registry available at

Credential Source Class

After the registration of an authenticator, you will get a Public Key Credential Source object. It contains all the credential data needed to perform user authentication and much more:

• The credential ID,

• The public key,

• The credential type (public_key),

• The transports (USB, NFC, BLE, internal),

• The attestation type,

• The trust path,

• The authenticator AAGUID,

• The user handle (i.e. the user ID)

• The authenticator counter,

• Other UI data

• ...

Since 4.6.0 and except if you use the Symfony bundle, there is no interface to implement or abstract class to extend so that it should be easy to integrate it in your application.

The loaded data needs to be verified. The library will perform several actions to make sure the input you received is valid. This verification process is performed by a Ceremony Step Manager (CSM). The Webauthn Specification distinguish two types of ceremonies.

To facilitate the creation of the CSM, a default factory is included. This factory requires no external services to function.

These CSM services are meant to be used by Response Validators. On a similar way, there are two types of validators:

• Authenticator Attestation Response Validator: used during the creation ceremony

• Authenticator Assertion Response Validator: used during the request ceremony

This framework provides a Symfony bundle that will help you to use the components within your Symfony application.

If you don't use Symfony Flex, you must register the bundle and route manually.

The first steps are:

• The creation of your

• The creation of your .

Extension Output Checker

An Extension Output Checker will check the extension output.

It must implement the interface Webauthn\AuthenticationExtensions\ExtensionOutputChecker and throw an exception of type Webauthn\AuthenticationExtension\ExtensionOutputError in case of error.

In the previous example, we asked for the location of the device and we expect to receive geolocation data in the extension output.

The easiest way to manage that is by using the creation and request profiles.

webauthn:
    …
    creation_profiles:
        default:
            rp:
                name: 'My Application'
                id: 'example.com'
            extensions:
                uvm: true
    request_profiles:
        default:
            rp_id: 'example.com'
            extensions:
                uvm: true

In general, the data you receive is an encoded JSON object. The library provides utilities to convert the string into objects.

To do so, you will need an Attestation Statement Support Manager and a Serializer.

Attestation Statement Support Manager

Authenticator Responses may contain an Attestation Statement. This attestation holds 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.

Supported Attestation Statement Types

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 FIDO / 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 (deprecated).

• trusted platform module: for devices with built-in security chips.

• apple: for Apple devices

To convert Authenticator Responses from the encoded string to an object, you will need a Serializer. It only needs the Attestation Statement Support Manager created above.

In general, the data you receive looks like as follows.

If the data is correctly loaded, the variable $publicKeyCredential will be an instance of Webauthn\PublicKeyCredential. An exception is thrown in case of an error.

The Credential Source can be stored the way you want. As the Webauthn\PublicKeyCredentialSource class can be converted into JSON, it could be stored in a filesystem.

It is up to you to create a credential source repository. This service shall implement Webauthn\Bundle\Repository\PublicKeyCredentialSourceRepositoryInterface

Registration Capability

By default, the User Entity Repository is not able to register any user account. You can add this behaviour by implementing the interface Webauthn\Bundle\Repository\CanRegisterUserEntity.

Doctrine Repository

In general, Symfony applications use Doctrine. That is why the bundle provides a way to use Doctrine as storage system.

The Doctrine Entity

Hereafter an example of an entity.

This is the most simple example. Feel free to add custom fields that fits on your needs e.g. created_at or is_revoked.

To ease the integration into your application, the bundle provides a concrete class that you can extend.

This repository should be declared as a Symfony service.

To authenticate or register your users with Symfony, the best and easiest way is to use the Security Bundle. First, install that bundle and follow the instructions given by .

At the end of the installation and configuration, you should have a config/packages/security.yaml file that looks like as follow:

To enable the user authentication, you just have to declare the webauthn authenticator if the appropriate firewall (here main).

As you have noticed, there is nothing to configure to have a fully functional firewall. The firewall routes are automatically created for you. They are namely:

With Webauthn, it is possible to authenticate a user without username. This behavior implies several constraints:

1. During the registration of the authenticator, a ,

2. The user verification is required,

3. The list of allowed authenticators must be empty

In order to prevent username enumeration, random credentials are set when a username is passed but no user entity is found.

A very simple service is provided. If you want to change the way the fake credentials are generated, you can create a custom service. The service shall implement the Webauthn\FakeCredentialGenerator interface.

Then, declare this service in the container and use it in your bundle configuration.

By default, any type of authenticator can be used by your users and interact with you application. In certain circumstances, you may need to select specific authenticators e.g. when user verification is required.

The Webauthn API and this library allow you to define a set of options to disallow the registration of authenticators that do not fulfill with the conditions.

The class Webauthn\AuthenticatorSelectionCriteria is designed for this purpose. It is used when generating the Webauthn\PublicKeyCredentialCreationOptions object.

Available Criteria

Authenticator Attachment Modality

You can indicate if the authenticator must be attached to the client (platform authenticator i.e. it is usually not removable from the client device) or must be detached (roaming authenticator).

Possible values are:

• AuthenticatorSelectionCriteria::AUTHENTICATOR_ATTACHMENT_NO_PREFERENCE: there is no requirement (default value),

• AuthenticatorSelectionCriteria::AUTHENTICATOR_ATTACHMENT_PLATFORM: the authenticator must be attached,

• AuthenticatorSelectionCriteria::AUTHENTICATOR_ATTACHMENT_CROSS_PLATFORM: must be a roaming authenticator.

A primary use case for platform authenticators is to register a particular client device as a "trusted device" for future authentication. This gives the user the convenience benefit of not needing a roaming authenticator, e.g., the user will not have to dig around in their pocket for their key fob or phone.

When this criterion is set to true, a Public Key Credential Source will be stored in the authenticator, client or client device. Such storage requires an authenticator capable to store such a resident credential.

This criterion is needed if you want to .

Webauthn defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users.

The complete specification can be found on the W3C dedicated page.

This framework contains PHP libraries and Symfony bundle to allow developers to integrate that authentication mechanism into their web applications.

Class, Constant and Property Names

Naming things may be complicated. That’s why the following rule applies on the whole framework: the name of classes, constants and properties are identical to the ones you will find in the specification.

As an example, the section 5.2.2 “Web Authentication Assertion” shows an object named AuthenticatorAssertionResponse that extends AuthenticatorResponse with the following properties:

• authenticatorData

• signature

• userHandle

  You will find in the PHP class provided by the library.

• Attestation Types

  • Empty

  • Basic

  • Self

• Attestation Formats

  • FIDO U2F

  • Packed

  • TPM

As of January 2023, our framework supports every authenticator with full feature and algorithm support, achieving a 100% success rate across all tests. Official FIDO Alliance testing tools have validated its compliance.

We ensure continuous conformity through rigorous unit and functional testing throughout the development process.

I bring solutions to your problems and answer your questions.

If you really love that project, and the work I have done or if you want I prioritize your issues, then !

Requests for new features, bug fixed and all other ideas to make this framework useful are welcome.

If you feel comfortable writing code, you could try to fix or .

Do not forget to follow .

First of all, thank you for contributing.

Bugs or feature requests can be posted online on the GitHub issues section of the project.

Few rules to ease code reviews and merges:

• You MUST follow the PSR-12 for coding standards.

• You MUST use the PSR-20 to get the time.

• You MUST run the test suite (see below).

• You MUST write (or update) tests when bugs are fixed or features are added.

• You SHOULD write documentation.

• You MAY follow the and .

We use the following branching workflow:

• Each minor version has a dedicated branch (e.g. 1.1.x, 1.2.x, 2.0.x, 2.1.x…)

• The default branch is set to the last minor version (e.g. v2.1.x).

To contribute use , please, write commit messages that make sense, and rebase your branch before submitting your PR.

• install composer: curl -s http://getcomposer.org/installer | php

• install dependencies: php composer.phar install

• run tests: vendor/bin/phpunit

You will interact with the authenticators through an HTML page and Javascript using the Webauthn API.

We highly recommend the use of @simplewebauthn/browser. This library provides lots of easy and useful features and it fully compliant with the specification.

If you use the Symfony UX, you may be interested in the Stimulus Controller.

The authenticators may have an internal counter. This feature is very helpful to detect cloned devices.

The default behaviour is to reject the assertions. This behaviour might cause some troubles as it could reject the real device whilst the fake one can continue to be used.

It is therefore required to go deeper in the protection of your application by logging the error and locking the associated account.

To do so , you have to create a custom Counter Checker and inject it to your Authenticator Assertion Response Validator. The checker must implement the interface Webauthn\Counter\CounterChecker.

<?php

declare(strict_types=1);


namespace App\Service;

use App\SecuritySystem;
use Assert\Assertion;
use Throwable;
use Webauthn\PublicKeyCredentialSource;

final class CustomCounterChecker implements CounterChecker
{
    private $securitySystem;

    public function __construct(SecuritySystem $securitySystem)
    {
        $this->securitySystem = $securitySystem ;
    }

    public function check(PublicKeyCredentialSource $publicKeyCredentialSource, int $currentCounter): void
    {
        try {
            Assertion::greaterThan($currentCounter, $publicKeyCredentialSource->getCounter(), 'Invalid counter.');
        } catch (Throwable $throwable) {
            $this->securitySystem->fakeDeviceDetected($publicKeyCredentialSource);
            throw $throwable;
        }
    }
}

The Counter Checker service can be injected to your Ceremony Step Manager Factory.

Webauthn is now supported by all main web browsers:

• Mozilla Firefox 60+ and Firefox for Android 68+

• Google Chrome 67+

• Microsoft EDGE 18+ and Microsoft EDGE Chromium 79+

• Opera 54+

• Safari 13+ and iOS Safari 13.3+

• Android Browser 76+

For more information and limitation on these browsers, please have a look at the following page:

During the Attestation Ceremony (i.e. the registration of the authenticator), you can ask for the Attestation Statement of the authenticator. The Attestation Statements have one of the following types:

• None (none): no Attestation Statement is provided

• Basic Attestation (basic): Authenticator’s attestation key pair is specific to an authenticator model.

This project follows the Semantic Versioning principles and, contrary to upgrade a minor version (where the middle number changes) where no difficulty should be encountered, upgrade a major version (where the first number changes) is subject to significant modifications.

Update the libraries

First of all, you have to make sure you are using the last 4.x release (4.8.0 at the time of writing).

In addition, you have to make sure you are using PHP 8.3+.

Spot deprecations

Next, you have to verify you don’t use any deprecated class, interface, method or property. If you have PHPUnit tests, you can easily get the list of deprecation used in your application.

PSR-20 Clock

In previous versions, the classes that requires time used the PHP time function directly. It is now required to use a PSR-20 Clock implementation and pass it to the classes.

• Webauthn\MetadataService\CertificateChain\PhpCertificateChainValidator

For version 3.2.0+ and the Symfony Bundle, an internal implementation service named jose.internal_clock existed and is removed.

The Android SafetyNet API is deprecated and is completely removed in 5.0.

All references to token binding are deprecated. This functionality is not supported anymore as removed from the latest Webauthn spectification versions.

All references to the ECDAA Attestation Statement type are deprecated. This functionality is not supported anymore as removed from the latest Webauthn spectification versions.

• Constant AuthenticatorSelectionCriteria::RESIDENT_KEY_REQUIREMENT_NONE: please use AuthenticatorSelectionCriteria::RESIDENT_KEY_REQUIREMENT_NO_PREFERENCE instead

This class is now deprecated. Please use Webauthn\MetadataService\CertificateChainChecker\PhpCertificateChainValidator instead or a class that implements Webauthn\MetadataService\CertificateChain\CertificateChainValidator.

As these values are redundant, the Id property is deprecated in 4.9.0 and will be removed in 5.0.0.

This class is removed in 5.0. You should use Symfony Serializer or create a dedicated serializer using Webauthn\Denormalizer\WebauthnSerializerFactory.

This interface is deprecated and removed. There is no replacement as it became useless for the library. The Symfony bundle uses its own interface Webauthn\Bundle\Repository you are asked to use in the Symfony context.

The PSR-17 and PSR-18 are not supported anymore. The library uses Symfony Http Client instead. A class is provided to help you to continue using PSR-* compatible libraries: Webauthn\MetadataService\Psr18HttpClient. This class is very basic and can be enhanced or overridden at will.

The following events are removed in favor of events located in the library namespace:

• Webauthn\Bundle\Event\AuthenticatorAssertionResponseValidationFailedEvent

• Webauthn\Bundle\Event\AuthenticatorAssertionResponseValidationSucceededEvent

• Webauthn\Bundle\Event\AuthenticatorAttestationResponseValidationFailedEvent

The following services are removed:

• webauthn.cose.algoritm.* (because of a typo)

• Webauthn\PublicKeyCredentialLoader

• Webauthn\PublicKeyCredentialSourceRepository

• Added:

  • symfony/clock

  • symfony/serializer

The following options are removed:

• webauthn.http_message_factory

• webauthn.token_binding_support_handler

• webauthn.creation_profiles[x].attachment_mode

When deprecations are removed, you can upgrade the libraries. In your composer.json, change all web-auth/* dependencies from ^4.x to ^5.0. When done, execute composer update.

When the libraries are up to date, you will need to perform a database migration.

The field type for transports and other_ui changed from array to json (array is now deprecated).

Hereafter an example of a Postgresql command:

Also, the trust path type key is not needed anymore and can be removed:

If you want to see all modifications at once, please .

The easiest way to manage the user verification requirements in your Symfony application is by using the creation and request profiles.

In the Webauthn context, there are two ceremonies:

• The attestation ceremony or creation ceremony: associates an authenticator to a user account

• The assertion ceremony or request ceremony: used for the authentication of a user.

For both ceremonies, there are two steps to perform:

1. The creation of options: these options are sent to the authenticator and indicate what to do and how.

2. The response of the authenticator: after the user interacted with the authenticator, the authenticator computes a response that has to be verified.

Depending on the options and the capabilities of the authenticator, the user interaction may differ. It can be a simple touch on a button or a complete authentication using biometric means (PIN code, fingerprint, facial recognition…).

This ceremony aims at registering an authenticator. It can be used during the creation of a new user account or when an existing user wants to add an additional authenticator.

This ceremony aims at authenticating a user. The user will be asked to interact with one of its authenticators. Additional authentication means, such as PIN code or fingerprint, may be required.

If you have troubles during the development of your application or if you want to keep track of every critical/error messages in production, you can use a PSR-3 compatible logger.

Several classes implement the interface Webauthn\MetadataService\CanLogData. This interface allows setting a PSR-3 logger instance.

User Entity Class

A User Entity object represents a user in the Webauthn context. It has the following constraints:

• The user ID must be unique and must be a string,

• The username must be unique,

Hereafter a minimalist example of user entity:

<?php

use Webauthn\PublicKeyCredentialUserEntity;

$userEntity = PublicKeyCredentialUserEntity::create(
    'john.doe',                             // Username
    'ea4e7b55-d8d0-4c7e-bbfa-78ca96ec574c', // ID
    'John Doe'                              // Display name
);

As for the rp Entity, the User Entity may have an icon. This icon must also be secured.

Except if you use the Symfony bundle, there is no interface to implement or abstract class to extend so that it should be easy to integrate it in your application. You may already have a user repository.

The Relying Party (or rp) corresponds to the application that will ask for the user to interact with the authenticator.

The library provides a simple class to handle the rp information: Webauthn\PublicKeyCredentialRpEntity.

<?php

use Webauthn\PublicKeyCredentialRpEntity;

$rpEntity = PublicKeyCredentialRpEntity::create(
    'ACME Webauthn Server' // The application name
);

This $rpEntity object will be useful for the next steps.

Relying Party ID

In the example above, we created a simple relying party object with it’s name. The relying party may also have an ID that corresponds to the domain applicable for that rp. By default, the relying party ID is null i.e. the current domain will be used.

It may be useful to specify the rp ID, especially if your application has several sub-domains. The rp ID can be set during the creation of the object as 2nd constructor parameter.

The rp ID shall be the domain of the application without the scheme, userinfo, port, path, user…. IP addresses are not allowed either.

The Relying Party ID should be determined depending on the common URLs for your web application.

If you have a web application that can be reached at (for mobiles) and or (for other devices), your Relying Party ID should be my-app.com.

If the domain is shared between sub-projects, the rp ID should be limited to that sub-projects.

For example, a web site is located at https://(www.)site1.host.com and another at https://(www.)site2.host.com, then the Relying Party IDs should be site1.host.com and site2.host.com respectively. If you set host.com, there is a risk that users from site1.host.com can log in at site2.host.com.

Your application may also have a logo. You can indicate this logo as third argument. Please note that for safety reason this icon is a priori authenticated URL i.e. an image that uses the data scheme.

Consider the following login form.

<form>
    <label for="username">Username</label>
    <input name="username" type="text" id="username" placeholder="Type your username here" autocomplete="username">
    
    <label for="password">Password</label>
    <input name="password" type="password" id="password" placeholder="Type your password here" autocomplete="password">
    
    <button type="submit">
        Sign in
    </button>
</form>

First step is to remove the password field that is no longer needed. In addition, we can indicate the autocomplete method is webauthn; this helps browser understanding the purpose of this field.

<form>
    <label for="username">Username</label>
    <input name="username" type="text" id="username" placeholder="Type your username here" autocomplete="username webauthn">

    <button type="submit">
        Sign in
    </button>
</form>

We now have only two Twig functions to call: stimulus_controller and stimulus_action.

• The first one is placed on the form level;

• The latter on the button.

The Stimulus Controller should be configured to fits on your needs. In particular, the routes to the options and authenticator result. The route names used below are automatically created by the firewall from the bundle package. By using these values, we make sure the routes are always in line with the firewall configuration.

The authenticators may have an internal counter. This feature is very helpful to detect cloned devices.

The default behaviour is to reject the assertions. This might cause some troubles as it could reject the real device whilst the fake one can continue to be used. You may also want to log the error, warn administrators or lock the associated user account.

To do so , you have to create a custom Counter Checker and inject it to your Authenticator Assertion Response Validator. The checker must implement the interface Webauthn\Counter\CounterChecker.

The following example is fictive and show how to lock a user, log the error and throw an exception.

An Authenticator is a cryptographic entity used to generate a public key credential and registered by a Relying Party (i.e. an application). This public key is used to authenticate by potentially verifying a user in the form of an authentication assertion and other data.

Authenticators may have additional features such as PIN code or biometric sensors (fingerprint, facial recognition…) that offer user verification.

The roaming authenticator may have different forms. The most common form is a USB device the user plugs into its computer. It can be a paired Bluetooth device or a card with NFC capabilities.

Authenticators of this class are removable from, and can "roam" among, client devices.

A platform authenticator is usually not removable from the client device. For example an Android smartphone or a Windows 10 computer with the associated security chips can act as an authenticator.

To set up a Webauthn server, you'll require components from two main categories:

• : serivces required to load the data and convert into DTO or other objects

• : services required to verify the input data and return the result of this validation

Upon completion, you'll have the capability to and .

Your application certainly has a user repository. Good news: there is no need to modify it!

The User Entity Repository can be completely decoupled from the user entity used by your application.

This repository should be declared as a Symfony service and shall implement Webauthn\Bundle\Repository\PublicKeyCredentialUserEntityRepositoryInterface.

Hereafter an example where the application User Repository is injected. This repository uses Doctrine and provides findOneBy* methods.

By default, the User Entity Repository is not able to register any user account. You can add this behaviour by implementing the following interfaces:

If you have troubles during the development of your application or if you want to keep track of every critical/error messages in production, you can use a .

User verification may be instigated through various authorization gesture modalities: a touch plus PIN code, password entry, or biometric recognition (presenting a fingerprint). The intent is to be able to distinguish individual users.

Eligible authenticators are filtered and only capable of satisfying this requirement will interact with the user.

Possible user verification values are:

• required: this value indicates that the application requires user verification for the operation and will fail the operation if the response does not have the UV flag set.

• preferred: this value indicates that the application prefers user verification for the operation if possible, but will not fail the operation if the response does not have the UV flag set.

• discouraged: this value indicates that the application does not want user verification employed during the operation (e.g.,in the interest of minimizing disruption to the user interaction flow).

Public constants are provided by AuthenticatorSelectionCriteria.

• AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_REQUIRED

• AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_PREFERRED

• AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_DISCOURAGED

If your are working on a development environment, https may not be available but the context could be considered as secured. You can bypass the scheme verification by passing the list of rpIds you consider secured.

If your are working on a development environment, https may not be available but the context could be considered as secured. You can bypass the scheme verification by passing the list of rpIds you consider secured.

During this step, your application will send a challenge to the device. The device will resolve this challenge by adding information and digitally signing the data.

The application will check the response from the device and get its credential ID. This ID will be used for further authentication requests.

Creation Request

To associate a device to a user, you need to instantiate a Webauthn\PublicKeyCredentialCreationOptions object.

It will need:

• The Relying Party

• The User data

• A challenge (random binary string)

• A list of supported public key parameters i.e. an algorithm list (at least one)

Optionally, you can customize the following parameters:

• A timeout

• A list of public key credential to exclude from the registration process

• The Authenticator Selection Criteria

• Attestation conveyance preference

Let’s see an example of the PublicKeyCredentialCreationOptions object. The following example is a possible Public Key Creation page for a dummy user "@cypher-Angel-3000".

The options object can be converted into JSON and sent to the authenticator .

You can change the default values for each and all options

The argument pubKeyCredParams contains a list of Webauthn\PublicKeyCredentialParameters objects that refer to COSE algorithms. The authenticators must use one of the algorithms in this list, respecting the order of preference on this list.

An empty list corresponds to the default algorithms that are ES256 and RS256 (in this order). Those two algorithms are required by the specification.

Please read detail .

Please read detail .

When the user already registered authenticators, you can pass a list of Webauthn\PublicKeyCredentialDescriptor objects as argument to avoid registering multiple times the same authenticator.

What you receive must be a JSON object that looks like as follow:

There are two steps to perform with this object:

Now that all components are set, we can load the data we receive using the (variable $serializer).

If no exception is thrown, you can go to the next step: the verification.

Now we have a fully loaded Public Key Credential object, but we need now to make sure that:

1. The authenticator response is of type AuthenticatorAttestationResponse

2. This response is valid.

The first step is easy to perform:

The second step is the verification against

• The Public Key Creation Options we created earlier,

• The URI host

The Authenticator Attestation Response Validator service (variable $authenticatorAttestationResponseValidator) will check everything for you: challenge, origin, attestation statement and much more.

If no exception is thrown, the response is valid. You can store the Public Key Credential Source ($publicKeyCredentialSource).

The Webauthn data verification is based on cryptographic signatures and thus you need to provide cryptographic algorithms to perform those checks.

The following algorithms are required in most situations:

<?php

declare(strict_types=1);

use Cose\Algorithm\Manager;
use Cose\Algorithm\Signature\ECDSA\ES256;
use Cose\Algorithm\Signature\RSA\RS256;

$algorithmManager = Manager::create()
    ->add(
        ES256::create(),
        RS256::create()
    )
;

The complete list of supported algorithms:

The algorithm manager can be injected to your Ceremony Step Manager Factory.

<?php

declare(strict_types=1);

use Webauthn\CeremonyStep\CeremonyStepManagerFactory;

$csmFactory = new CeremonyStepManagerFactory();
$csmFactory->setAlgorithmManager($algorithmManager);

With Symfony, you must enable this feature and define a Metadata Statement Repository in the configuration file.

webauthn:
    metadata_service:
        enabled: true
        repository: 'App\Repository\MyMetadataStatementRepository'

Credential Creation Options

By default, no Attestation Statement is asked to the Authenticators (type = none). To change this behavior, you just have to set the corresponding parameter in the Webauthn\PublicKeyCredentialCreationOptions object.

There are 3 conveyance modes available using PHP constants provided by the class Webauthn\PublicKeyCredentialCreationOptions:

• ATTESTATION_CONVEYANCE_PREFERENCE_NONE: the Relying Party is not interested in authenticator attestation (default)

• ATTESTATION_CONVEYANCE_PREFERENCE_INDIRECT: the Relying Party prefers an attestation conveyance yielding verifiable attestation statements, but allows the client to decide how to obtain such attestation statements.

• ATTESTATION_CONVEYANCE_PREFERENCE_DIRECT: the Relying Party wants to receive the attestation statement as generated by the authenticator.

• ATTESTATION_CONVEYANCE_PREFERENCE_ENTERPRISE: the Relying Party wants to receive uniquely identifying information from authenticators.

With Webauthn, it is possible to authenticate a user without username. This behavior implies several constraints:

1. During the registration of the authenticator, a Resident Key must have been asked,

2. The user verification is required,

3. The list of allowed authenticators must be empty

The bundle configuration should have a profile with the constraints listed above:

Configuration

With Flex, you have a minimal configuration file installed through a Flex Recipe. You must set the repositories you have just created. You also have to modify the environment variables Relying_PARTY_ID and Relying_PARTY_NAME.

You may also need to adjust other parameters.

If you don’t use Flex, hereafter an example of configuration file:

webauthn:
#    logger: null # PSR-3 compatible logging service
    credential_repository: 'Webauthn\Bundle\Repository\DummyPublicKeyCredentialSourceRepository' # CREATE YOUR REPOSITORY AND CHANGE THIS!
    user_repository: 'Webauthn\Bundle\Repository\DummyPublicKeyCredentialUserEntityRepository' # CREATE YOUR REPOSITORY AND CHANGE THIS!
    token_binding_support_handler: 'Webauthn\TokenBinding\IgnoreTokenBindingHandler' # We ignore the token binding instructions by default
    creation_profiles: # Authenticator registration profiles
        default: # Unique name of the profile
            rp: # Relying Party information
                name: '%env(Relying_PARTY_NAME)%' # CHANGE THIS! or create the corresponding env variable
                id: '%env(Relying_PARTY_ID)%' # Please adapt the env file with the correct relying party ID or set null
#                icon: null # Secured image (data:// scheme)
#            challenge_length: 32
#            timeout: 60000
#            authenticator_selection_criteria:
#                attachment_mode: !php/const Webauthn\AuthenticatorSelectionCriteria::AUTHENTICATOR_ATTACHMENT_NO_PREFERENCE
#                require_resident_key: false
#                user_verification: !php/const Webauthn\AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_PREFERRED
#            extensions:
#                loc: true
#            public_key_credential_parameters: # You should not change this list
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_EdDSA #Order is important. Preferred algorithms go first
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_ES256
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_ES256K
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_ES384
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_ES512
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_RS256
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_RS384
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_RS512
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_PS256
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_PS384
#                - !php/const Cose\Algorithms::COSE_ALGORITHM_PS512
#            attestation_conveyance: !php/const Webauthn\PublicKeyCredentialCreationOptions::ATTESTATION_CONVEYANCE_PREFERENCE_NONE
    request_profiles: # Authentication profiles
        default: # Unique name of the profile
            rp_id: '%env(Relying_PARTY_ID)%' # Please adapt the env file with the correct relying party ID or set null
#            challenge_length: 32
#            timeout: 60000
#            user_verification: !php/const Webauthn\AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_PREFERRED
#            extensions:
#                loc: true
#    metadata:
#        enabled: false
#        mds_repository: 'App\Repository\MetadataStatementRepository'
#        status_report_repository: 'App\Repository\StatusReportRepository'
#        certificate_chain_checker: 'App\Security\CertificateChainChecker'

Creation Profiles

Relying Party (rp)

The relying Party corresponds to your application. Please refer to this page for more information.

Challenge Length

By default, the length of the challenge is 32 bytes. You may need to select a smaller or higher length. This length can be configured for each profile:

webauthn:
    creation_profiles:
        acme:
            rp:
                name: 'ACME Webauthn Server'
            challenge_length: 16

Timeout

The default timeout is set to 60 seconds (60 000 milliseconds). You can change this value as follows:

webauthn:
    creation_profiles:
        acme:
            rp:
                name: 'ACME Webauthn Server'
            timeout: 30000

Authenticator Selection Criteria

This set of options allows you to select authenticators depending on their capabilities. The values are described in of the protocol.

This option indicates the algorithms allowed for your application. By default, a large list of algorithms is defined, but you can add custom algorithms or reduce the list.

If you need the , you can specify the preference regarding attestation conveyance during credential generation.

You can set as many extensions as you want in the profile. Please also for more information.

The parameters for the request profiles (i.e. the authentication) are very similar to the creation profiles. The only difference is that you don’t need all the detail of the Relying Party, but only its ID (i.e. its domain).

Please note that all parameters are optional. The following configuration is perfectly valid. However, and as mentioned above, the parameter id is highly recommended.

In some circumstances, you may need to register a new authenticator for a user e.g. when adding a new authenticator or when an administrator acts as another user to replace a lost device.

It is possible to perform this ceremony programmatically.

With a Symfony application, the fastest way for a user to register additional authenticators is to use the “controller” feature.

To add a new authenticator to a user, the bundle needs to know to whom it should be added. This can be:

• The current user itself e.g. from its own account

• An administrator acting for another user from a dashboard

For that purpose, a User Entity Guesser service should be created. This service shall implement the interface Webauthn\Bundle\Security\Guesser\UserEntityGuesser and its unique method findUserEntity.

You can directly use the Webauthn\Bundle\Security\Guesser\CurrentUserEntityGuesser as a Symfony service. It is designed to identify the user that is currently logged in.

In the example herafter where the current user is guessed using a controller parameter. This can be used when an administrator is adding an authenticator to another user account.

Now you just have to enable the feature and set the routes to your options and response controllers.

Now you can send requests to these new endpoints. For example, if you are using the Javascript library, the calls will look like as follow:

The default is used. You can change it using the dedicated option.

You can customize the responses returned by the controllers by using custom handlers. This could be useful when you want to return additional information to your application.

There are 3 types of responses and handlers:

• Creation options,

• Success,

• Failure.

This handler is called during the registration of a authenticator and has to implement the interface Webauthn\Bundle\Security\Handler\CreationOptionsHandler.

This handler is called when a client sends a valid assertion from the authenticator. This handler shall implement the interface Webauthn\Bundle\Security\Handler\SuccessHandler. The default handler is Webauthn\Bundle\Service\DefaultSuccessHandler.

This handler is called when an error occurred during the process. This handler shall implement the interface Webauthn\Bundle\Security\Handler\SuccessHandler. The default handler is Webauthn\Bundle\Service\DefaultFailureHandler.