A simple PHP WebAuthn (FIDO2) server to demonstration a user on how to login with Hirsch's uTrust key.
See /_test for a simple usage of this library. Check https://fido2.lovestoblog.com/_test/demo.html for a working example.
- uTrust FIDO2 GOV Security Keys
- uTrust FIDO2 NFC+ Security Keys
- uTrust FIDO2 NFC Security Keys
- uTrust FIDO2 Card
Note
- FIDO2 GOV runs FIDO2.1
- FIDO2 NFC runs FIDO2.0
- Max resident keys supported is 28
- Max number of resident keys per relying party is 10
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 <----------------'
Note
This library supports authenticators that are signed with an X.509 certificate or that are self-attested. ECDAA is not supported.
- android-key ✅
- android-safetynet ✅
- apple ✅
- fido-u2f ✅
- none ✅
- packed ✅
- tpm ✅
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, 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.
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 probably what you want to use if you want secure login for a public website.
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 cannot validate against any root CA if the browser uses an anonymization certificate. This library sets attestation to indirect if you select multiple formats but don't provide any root CA.
Tip
A hybrid solution. Clients may be discouraged by browser warnings, but then you know what device they're using (statistics rulez!).
The browser provides data about the identificator device, which can be identified uniquely. Users could be tracked across multiple sites. Because of this, the browser may show a warning message about providing this data during registration. This library sets attestation to direct if you select multiple formats and provide root CAs.
Tip
This is probably what you want if you know what devices your clients are using and want to ensure that only these devices are used.
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 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 from client-side discoverable credentials. The difference is only that the phone or computer system automatically syncs the credentials between the user’s devices via a cloud service. The cross-device sync of passkeys is managed transparently by the OS.
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.
When calling WebAuthn\WebAuthn->getCreateArgs, set $requireResidentKey to true
to notify the authenticator that it should save the registration in its memory.
When calling WebAuthn\WebAuthn->getGetArgs, don't provide any $credentialIds (the authenticator will look up the IDs in its own memory and return 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).
The RP ID (= domain) is saved on the authenticator. If an authenticator is lost, it is theoretically possible to find the services it was used against and login there.
Availability of built-in passkeys that automatically synchronize to all of a user’s devices: (see also passkeys.dev/device-support)
- Apple iOS 16+ / iPadOS 16+ / macOS Ventura+
- Android 9+
- Microsoft Windows 11 23H2+
- PHP >= 8.0 with OpenSSL and Multibyte String
- Browser with WebAuthn support (Firefox 60+, Chrome 67+, Edge 18+, Safari 13+)
- PHP Sodium (or Sodium Compat ) for Ed25519 support