For the complete documentation index, see llms.txt. This page is also available as Markdown.

Register Authenticators

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 credentials to exclude from the registration process

  • The Authenticator Selection Criteria

  • Attestation conveyance preference

  • Extensions

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 using the API.

You can change the default values for each and all options

Public Key Credential Parameters

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.

Authenticator Selection

Please read detail on this page.

Attestation

Please read detail on this page.

Hints

New in v5.3.0

WebAuthn Level 3 lets the relying party suggest one or several authentication methods through the hints parameter. The user agent uses the list (in order) to tailor the prompt — for example, showing the QR code for hybrid transport first.

The valid values are exposed as constants on Webauthn\PublicKeyCredentialOptions:

  • HINT_SECURITY_KEY (security-key) — external security key (e.g. YubiKey)

  • HINT_CLIENT_DEVICE (client-device) — platform authenticator (Touch ID, Windows Hello…)

  • HINT_HYBRID (hybrid) — phone as authenticator over the hybrid transport

The same hints parameter is available on PublicKeyCredentialRequestOptions for authentication ceremonies.

Exclude Credentials

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.

Creation Response

What you receive must be a JSON object that looks like the following:

There are two steps to perform with this object:

Data Loading

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

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

Response 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 Credential Record ($credentialRecord).

The way you store and associate these objects to the user is out of scope of this library.

Last updated

Was this helpful?