@simplewebauthn/browser
Advanced tools
Changelog
v5.0.0 The one with more insights
Packages:
Changes:
startRegistration()
and
startAuthentication()
will now return descriptions with more specific insights into what went
wrong (#184)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,
});
Changelog
v4.1.0
Packages:
Changes:
platformAuthenticatorIsAvailable()
now checks that WebAuthn is supported at all
before attempting to query for the status of an available platform authenticator.MetadataService.initialize()
gained a new verificationMode
option that can be set
to "permissive"
to allow registration response verification to continue when an unregistered
AAGUID is encountered. Default behavior, that fails registration response verification, is
represented by the alternative value "strict"
; MetadataService continues to default to this more
restrictive behavior.Changelog
v4.0.0 - The one with some new names
A lot has happened to me since I first launched SimpleWebAuthn back in May 2020. My understanding of WebAuthn has grown by leaps and bounds thanks in part to my representing Duo/Cisco in the W3C's WebAuth Adoption Working Group. I'm now in a point in my life in which it's no longer sufficient to think, "what's in SimpleWebAuthn's best interests?" Now, I have an opportunity to think bigger - "what's in the WebAuthn API's best interests?"
While early on I thought "attestation" and "assertion" were important names to WebAuthn, I've since come to better appreciate the spec's efforts to encourage the use of "registration" and "authentication" instead. To that end I decided it was time to rename all of the project's various public methods and types to get as much as possible to use "registration" and "authentication" instead.
This release is one of the more disruptive because it affects everyone who's used SimpleWebAuthn to date. The good news is that, while method and type names have changed, their capabilities remain the same. Updating your code to this version of SimpleWebAuthn should only involve renaming existing method calls and type annotations.
Please take the time to read the entire changelog for this release! There are a handful of new features also included that users with advanced use cases will find helpful. The simple use cases of the library remain unchanged - most new features are for power users who require extra scrutiny of authenticators that interact with their website and are otherwise opt-in as needed.
Packages:
Changes:
platformAuthenticatorIsAvailable()
has been
added for detecting when hardware-bound authenticators like Touch ID, Windows Hello, etc... are
available for use.
More info is available here.SettingsService
can be used to configure aspects of SimpleWebAuthn like
root certs for enhanced registration response verification or for validating FIDO MDS BLOBs with
MetadataService.
More info is available here.'android-key'
, 'android-safetynet'
, 'apple'
'@simplewebauthn/server/helpers'
(not a new package, but a subpath.) These methods can be used,
for example, to process non-standard responses that are not officially part of the WebAuthn spec
and thus unlikely to ever be supported by SimpleWebAuthn.MetadataService
now supports
FIDO Alliance Metadata Service version 3.0.The quickest way to update your code is to try changing "attestation" to "registration" and "assertion" to "authentication" in the name of whatever method or type is no longer working and see if that fixes it (exceptions to this rule are called out with asterisks below.) If it doesn't, check out PR #147 to see all of the renamed methods and types and try to cross-reference the original to see what it was renamed to.
Examples:
generateAttestationOptions()
->generateRegistrationOptions()
GenerateAttestationOptionsOpts
->GenerateRegistrationOptionsOpts
verifyAssertionResponse()
->verifyAuthenticationResponse()
VerifiedAttestation
->VerifiedRegistrationResponse
(*)VerifiedAssertion
->VerifiedAuthenticationResponse
(*)startAttestation()
->startRegistration()
startAssertion()
->startAuthentication()
These examples are not a comprehensive list of all the renamed methods! Rather these are examples of how method names were changed to try and eliminate "attestation" and "assertion" from the public API of both @simplewebauthn/browser and @simplewebauthn/server.
opts
argument for MetadataService.initialize()
is now optional.opts.mdsServers
argument for MetadataService.initialize(opts)
is now a simple
array of URL strings to FIDO Alliance MDSv3-compatible servers. If no value is specified then
MetadataService will query the
official FIDO Alliance Metadata Service version 3.0.See here for more information about the updated
MetadataService
.
supportsWebAuthn()
has been renamed to browserSupportsWebAuthn()
in an
effort to make the method convey a clearer idea of what supports WebAuthn.Changelog
v3.1.0
Packages:
Changes:
tslib
dependency for
production is no longer necessary as transpilation to ES5 is now fully the responsibility of the
framework implementing @simplewebauthn/browser.
Changelog
v3.0.0 - The one with a legacy
This release is focused on updating @simplewebauthn/browser for better browser support out of the box. Most projects will now pull in its (slightly larger) ES5 bundle to ensure maximum browser compatibility, including older browsers in which WebAuthn will never be available. The ES2018 build is still available for projects that only need to target newer browsers, but bundler configuration changes must now be made to include it instead of the ES5 build.
Packages:
Changes:
startAssertion()
no longer Base64URL-encodes userHandle
stringjsrsasign
to 10.2.0
(see
GHSA-27fj-mc8w-j9wg)startAssertion()
fixresponse.userHandle
as returned from startAssertion()
.Changelog
v2.2.1
Packages:
Changes:
Changelog
v2.1.0
Packages:
Changes:
startAttestation()
and startAssertion()
now include extension results as
clientExtensionResults
in their return valuePublicKeyCredentialCreationOptionsJSON
and
PublicKeyCredentialRequestOptionsJSON
types with new optional extensions
property to
support specifying WebAuthn extensions when calling generateAttestationOptions()
and
generateAssertionOptions()
AttestationCredentialJSON
and AssertionCredentialJSON
types with new clientExtensionResults
properties to contain output from WebAuthn's
credential.getClientExtensionResults()
Changelog
v2.0.0 - The one with -less and more Buffers
This major release includes improvements intended to make it easier to support passwordless and usernameless WebAuthn flows. Additional information returned from attestation verification can be used by RP's to further scrutinize the attestation now or in the future.
I also made the decision to reduce the amount of encoding from Buffer to Base64URL and decoding from Base64URL to Buffer throughout the library. Verification methods now return raw Buffers so that RP's are free to store and retrieve these values as they see fit without the library imposing any kind of encoding overhead that may complicate storage in a database, etc...
Packages:
Changes:
verifyAttestationResponse()
now returns a different data structure
with additional information that RP's can use to more easily support passwordless and usernameless
WebAuthn flows.
Buffer
values are now returned in place of previously-base64url-encoded values.
This is intended to offer more flexibility in how these values are persisted without imposing an
encoding scheme that may introduce undesirable overhead.Before:
type VerifiedAttestation = {
verified: boolean;
userVerified: boolean;
authenticatorInfo?: {
fmt: ATTESTATION_FORMAT;
counter: number;
base64PublicKey: string;
base64CredentialID: string;
};
};
After:
type VerifiedAttestation = {
verified: boolean;
attestationInfo?: {
fmt: ATTESTATION_FORMAT;
counter: number;
aaguid: string;
credentialPublicKey: Buffer;
credentialID: Buffer;
credentialType: string;
userVerified: boolean;
attestationObject: Buffer;
};
};
verifyAssertionResponse()
now returns a different data structure to
align with changes made to verifyAttestationResponse()
.Before:
type VerifiedAssertion = {
verified: boolean;
authenticatorInfo: {
counter: number;
base64CredentialID: string;
};
};
After:
type VerifiedAssertion = {
verified: boolean;
assertionInfo: {
credentialID: Buffer;
newCounter: number;
};
};
excludeCredentials
argument in generateAttestationOptions()
now expects a
Buffer
type for a credential's id
property. Previously id
needed to be a string
. Existing
credential IDs stored in base64url encoding can be easily converted to Buffer with a library like
base64url
:Before:
const options = generateAttestationOptions({
// ...
excludeCredentials: [{
id: 'PPa1spYTB680cQq5q6qBtFuPLLdG1FQ73EastkT8n0o',
// ...
}],
// ...
});
After:
const options = generateAttestationOptions({
// ...
excludeCredentials: [{
id: base64url.toBuffer('PPa1spYTB680cQq5q6qBtFuPLLdG1FQ73EastkT8n0o'),
// ...
}],
// ...
});
allowCredentials
argument in generateAssertionOptions()
now expects a
Buffer
type for a credential's id
property. Previously id
needed to be a string
. Existing
credential IDs stored in base64url encoding can be easily converted to Buffer with a library like
base64url
:Before:
const options = generateAssertionOptions({
// ...
allowCredentials: [{
id: 'PPa1spYTB680cQq5q6qBtFuPLLdG1FQ73EastkT8n0o',
// ...
}],
// ...
});
After:
const options = generateAssertionOptions({
// ...
allowCredentials: [{
id: base64url.toBuffer('PPa1spYTB680cQq5q6qBtFuPLLdG1FQ73EastkT8n0o'),
// ...
}],
// ...
});
AuthenticatorDevice
type has been updated to expect Buffer
's for
credential data. Naming of its properties have also been updated to help maintain consistency with
naming in the WebAuthn spec:Before:
type AuthenticatorDevice = {
publicKey: Base64URLString;
credentialID: Base64URLString;
counter: number;
transports?: AuthenticatorTransport[];
};
After:
type AuthenticatorDevice = {
credentialPublicKey: Buffer;
credentialID: Buffer;
counter: number;
transports?: AuthenticatorTransport[];
};
Changelog
v1.0.0 - The one that gets things out of "Beta"
Packages:
Changes:
verifyAttestationResponse()
and verifyAssertionResponse()
generateAttestationOptions()
to force legacy
authenticatorSelection.requireResidentKey
to true
when authenticatorSelection.residentKey
is
"required"
(as per L2 of the WebAuthn spec)AuthenticatorDevice
type with optional transports
propertyThere are no breaking changes in this release. Several recent minor changes presented an opportunity to release a "v1.0". I'd received enough positive feedback about SimpleWebAuthn and noticed growing usage which granted me the confidence to take advantage of this opportunity.
And perhaps this will give the project more legitimacy in the eyes of larger organizations wishing to use it but waiting for the libraries to "get out of beta"...