Download the PHP package lbuchs/webauthn without Composer

On this page you can find all versions of the php package lbuchs/webauthn. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package webauthn

Licensed under the MIT License Requires PHP 7.1.0 Last Commit

WebAuthn

A simple PHP WebAuthn (FIDO2) server library

Goal of this project is to provide a small, lightweight, understandable library to protect logins with passkeys, security keys like Yubico or Solo, fingerprint on Android or Windows Hello.

Manual

See /_test for a simple usage of this library. Check webauthn.lubu.ch for a working example.

Supported attestation statement formats

[!NOTE] This library supports authenticators which are signed with a X.509 certificate or which are self attested. ECDAA is not supported.

Workflow

         JAVASCRIPT            |          SERVER
------------------------------------------------------------
                         REGISTRATION

   window.fetch  ----------------->     getCreateArgs
                                             |
navigator.credentials.create   <-------------'
        |
        '------------------------->     processCreate
                                             |
      alert ok or fail      <----------------'

------------------------------------------------------------
                      VALIDATION

   window.fetch ------------------>      getGetArgs
                                             |
navigator.credentials.get   <----------------'
        |
        '------------------------->      processGet
                                             |
      alert ok or fail      <----------------'

Attestation

Typically, when someone logs in, you only need to confirm that they are using the same device they used during registration. In this scenario, you do not require any form of attestation. However, if you need additional security, such as when your company mandates the use of a Solokey for login, you can verify its authenticity through direct attestation. Companies may also purchase authenticators that are signed with their own root certificate, enabling them to validate that an authenticator is affiliated with their organization.

no attestation

just verify that the device is the same device used on registration. You can use 'none' attestation with this library if you only check 'none' as format.

[!TIP] this is propably what you want to use if you want secure login for a public website.

indirect attestation

the browser may replace the AAGUID and attestation statement with a more privacy-friendly and/or more easily verifiable version of the same data (for example, by employing an anonymization CA). You can not validate against any root ca, if the browser uses a anonymization certificate. this library sets attestation to indirect, if you select multiple formats but don't provide any root ca.

[!TIP] hybrid soultion, clients may be discouraged by browser warnings but then you know what device they're using (statistics rulez!)

direct attestation

the browser proviedes data about the identificator device, the device can be identified uniquely. User could be tracked over multiple sites, because of that the browser may show a warning message about providing this data when register. this library sets attestation to direct, if you select multiple formats and provide root ca's.

[!TIP] this is probably what you want if you know what devices your clients are using and make sure that only this devices are used.

Passkeys / Client-side discoverable Credentials

A Client-side discoverable Credential Source is a public key credential source whose credential private key is stored in the authenticator, client or client device. Such client-side storage requires a resident credential capable authenticator. This is only supported by FIDO2 hardware, not by older U2F hardware.

[!NOTE] Passkeys is a technique that allows sharing credentials stored on the device with other devices. So from a technical standpoint of the server, there is no difference to client-side discoverable credentials. The difference is only that the phone or computer system is automatically syncing the credentials between the user’s devices via a cloud service. The cross-device sync of passkeys is managed transparently by the OS.

How does it work?

In a typical server-side key management process, a user initiates a request by entering their username and, in some cases, their password. The server validates the user's credentials and, upon successful authentication, retrieves a list of all public key identifiers associated with that user account. This list is then returned to the authenticator, which selects the first credential identifier it issued and responds with a signature that can be verified using the public key registered during the registration process.

In a client-side key process, the user does not need to provide a username or password. Instead, the authenticator searches its own memory to see if it has saved a key for the relying party (domain). If a key is found, the authentication process proceeds in the same way as it would if the server had sent a list of identifiers. There is no difference in the verification process.

How can I use it with this library?

on registration

When calling WebAuthn\WebAuthn->getCreateArgs, set $requireResidentKey to true, to notify the authenticator that he should save the registration in its memory.

on login

When calling WebAuthn\WebAuthn->getGetArgs, don't provide any $credentialIds (the authenticator will look up the ids in its own memory and returns the user ID as userHandle). Set the type of authenticator to hybrid (Passkey scanned via QR Code) and internal (Passkey stored on the device itself).

disadvantage

The RP ID (= domain) is saved on the authenticator. So If an authenticator is lost, its theoretically possible to find the services, which the authenticator is used and login there.

device support

Availability of built-in passkeys that automatically synchronize to all of a user’s devices: (see also passkeys.dev/device-support)

Requirements

Infos about WebAuthn

FIDO2 Hardware

All versions of webauthn with dependencies

PHP Build Version
Package Version
Requires php Version >=8.0.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package lbuchs/webauthn contains the following files

Loading the files please wait ....