Skip to content

Releases: MasterKale/SimpleWebAuthn

v5.4.2

08 Aug 23:36
Compare
Choose a tag to compare

Packages:

Changes:

  • [server] Add support for "rsa_emsa_pkcs1_sha256_raw" and "rsa_emsa_pkcs1_sha256_der" authentication algorithms in FIDO MDS metadata statements (#241)

v5.4.1

06 Aug 05:39
Compare
Choose a tag to compare

Packages:

Changes:

  • [browser] "type": "module" has been added to package.json to appease modern front end tooling that expects this value to be present when using the ESM build (#237)
  • [server] TPM attestation statement verification now properly verifies statements with ECC public area type (#239)

v5.4.0

28 Jul 22:35
Compare
Choose a tag to compare

Packages:

Changes:

  • [server] verifyRegistrationResponse() and verifyAuthenticationResponse() now return authenticator extension data upon successful verification as the new authenticatorExtensionResults property (#230)
  • [browser] Code quality improvements
  • [typescript-types] Code quality improvements

v5.3.0

13 Jul 20:57
Compare
Choose a tag to compare

Packages:

Changes:

  • [browser] startAuthentication() now accepts a second useBrowserAutofill boolean argument that sets up support for credential selection via a browser's autofill prompt (a.k.a. Conditional UI). The new browserSupportsWebAuthnAutofill() helper method can be used independently to determine when this feature is supported by the browser (#214)
  • [browser] startRegistration() and startAuthentication() will return a new authenticatorAttachment value when present that captures whether a cross-platform or platform authenticator was just used (#221)
  • [typescript-types] A new PublicKeyCredentialFuture interface has been added to define new properties currently defined in the WebAuthn L3 spec draft. These new values support the above new functionality until official TypeScript types are updated accordingly (#214, #221)
  • [typescript-types] A new "hybrid" transport has been added to AuthenticatorTransportFuture while browsers migrate away from the existing "cable" transport for cross-device auth (#222)

v5.2.1

18 May 23:57
Compare
Choose a tag to compare

Packages:

Changes:

  • [server] generateRegistrationOptions() and generateAuthenticationOptions() will stop reporting typing errors for definitions of excludeCredentials and allowCredentials that were otherwise fine before v5.2.0 (#203)
  • [typescript-types] The new AuthenticatorTransportFuture and PublicKeyCredentialDescriptorFuture have been added to track changes to WebAuthn that outpace TypeScript's DOM lib typings
  • [browser] Version sync

v5.2.0

17 May 06:13
Compare
Choose a tag to compare

Packages:

Changes:

  • [browser, typescript-types] The new "cable" transport is now recognized as a potential value of the AuthenticatorTransport type (#198)
  • [server] verifyRegistrationResponse() and verifyAuthenticationResponse() now return credentialDeviceType and credentialBackedUp within authenticatorInfo as parsed values of two new flags being added to authenticator data. These response verification methods will also now throw an error when the invalid combination of these two flags (credentialDeviceType: "singleDevice", credentialBackedUp: true) is detected (#195)

v5.1.0

13 Apr 15:44
Compare
Choose a tag to compare

Packages:

Changes:

  • [browser] Custom errors raised when calling startRegistration() and startAuthentication() will now have the same name property as the original error (#191)
  • [server] Cleaned up code and added tests (#192, #193)

v5.0.0 - The one with more insights

02 Apr 17:34
Compare
Choose a tag to compare

Packages:

Changes:

  • [browser] Most common WebAuthn errors that can occur when calling startRegistration() and startAuthentication() will now return descriptions with more specific insights into what went wrong (#184)
  • [testing] Version sync
  • [typescript-types] Version sync

Breaking Changes

  • [server] The fidoUserVerification argument to verifyAuthenticationResponse() has been replaced with the simpler requireUserVerification boolean (#181)

Previous values of "required" should specify true for this new argument; previous values of "preferred" or "discouraged" should specify false:

Before:

const verification = verifyAuthenticationResponse({
  // ...snip...
  fidoUserVerification: 'required',
});

After:

const verification = verifyAuthenticationResponse({
  // ...snip...
  requireUserVerification: true,
});

v4.4.0

11 Feb 22:04
Compare
Choose a tag to compare

Packages:

Changes:

  • [server] Attestation statement verification involving FIDO metadata now correctly validates the credential public keypair algorithm against possible algorithms defined in the metadata statement.
  • [server] The expired GlobalSign R2 root certificate for "android-safetynet" responses has been removed
  • [server] Certificate path validation errors will now identify which part of the chain and which certificate has an issue
  • [server] verifyAuthenticationResponse()'s expectedChallenge argument also accepts a function that accepts a Base64URL string and returns a boolean to run custom logic against the clientDataJSON.challenge returned by the authenticator (see v4.3.0 release notes for more info).

v4.3.0

02 Feb 06:33
Compare
Choose a tag to compare

Packages:

Changes:

  • [server] The expectedChallenge argument passed to verifyRegistrationResponse() can now be a function that accepts a Base64URL string and returns a boolean to run custom logic against the clientDataJSON.challenge returned by the authenticator. This allows for arbitrary data to be included in the challenge so it can be signed by the authenticator.

After generating registration options, the challenge can be augmented with additional data:

const options = generateRegistrationOptions(opts);

// Remember the plain challenge
inMemoryUserDeviceDB[loggedInUserId].currentChallenge = options.challenge;

// Add data to be signed
options.challenge = base64url(JSON.stringify({
  actualChallenge: options.challenge,
  arbitraryData: 'arbitraryDataForSigning',
}));

Then, when invoking verifyRegistrationResponse(), pass in a method for expectedChallenge to parse the challenge and return a boolean:

const expectedChallenge = inMemoryUserDeviceDB[loggedInUserId].currentChallenge;

const verification = await verifyRegistrationResponse({
  expectedChallenge: (challenge: string) => {
    const parsedChallenge = JSON.parse(base64url.decode(challenge));
    return parsedChallenge.actualChallenge === expectedChallenge;
  },
  // ...
});

To retrieve the arbitrary data afterwards, use decodeClientDataJSON() afterwards to get it out:

import { decodeClientDataJSON } from '@simplewebauthn/server/helpers';

const { challenge } = decodeClientDataJSON(response.clientDataJSON);
const parsedChallenge = JSON.parse(base64url.decode(challenge));
console.log(parsedChallenge.arbitraryData); // 'arbitraryDataForSigning'