Version 2.0.0
This release removes deprecated APIs and changes some defaults to better align with the L2 version of the WebAuthn spec. It also adds a new major feature: optional integration with the FIDO Metadata Service for retrieving authenticator metadata and attestation trust roots. See below for details.
webauthn-server-core:
Breaking changes:
- Deleted deprecated
iconfield inRelyingPartyIdentityandUserIdentity, and its associated methods. - Deleted deprecated
AuthenticatorSelectionCriteriamethodsbuilder().requireResidentKey(boolean)andisRequireResidentKey(). RelyingPartyparameterallowUnrequestedExtensionsremoved. The library will now always accept unrequested extensions.- Class
ClientAssertionExtensionOutputsnow silently ignores unknown extensions instead of rejecting them. webauthn-server-core-minimalmodule deleted.webauthn-server-coreno longer depends on BouncyCastle and will no longer attempt to automatically fall back to it. Therefore, EdDSA keys are no longer supported by default in JDK 14 and earlier. The library will log warnings if configured for algorithms with no JCA provider available, in which case the dependent project may need to add additional dependencies and configure JCA providers externally.- Enum value
AttestationType.ECDAAremoved without replacement. - Deleted methods
RegistrationResult.getWarnings()andAssertionResult.getWarnings()since they are now always empty. - Framework for attestation metadata has been fully overhauled. See the
webauthn-server-attestationmodule documentation for the new ways to work with attestation metadata:- Deleted method
RegistrationResult.getAttestationMetadata(). - Interface
MetadataServicereplaced withAttestationTrustSource, and optionalRelyingPartysetting.metadataService(MetadataService)replaced with.attestationTrustSource(AttestationTrustSource). - Deleted types
AttestationandTransport. - Deleted method
AuthenticatorTransport.fromU2fTransport.
- Deleted method
RelyingParty.finishRegistration()now uses a JCACertPathValidatorto validate attestation certificate paths, if an attestation trust source has been configured. This requires a compatible JCA provider, but should already be available in most environments.- Classes in package
com.yubico.fido.metadatamoved tocom.yubico.webauthn.extension.uvmto avoid name clash withwebauthn-server-attestationmodule in JPMS. - Changed return type of
PublicKeyCredentialRequestOptions.getUserVerification(),AuthenticatorSelectionCriteria.getUserVerification()andAuthenticatorSelectionCriteria.getResidentKey()toOptional, and changed defaults foruserVerificationandresidentKeyto empty. This means we won't inadvertently suppress warnings that browsers might issue in the browser console if for exampleuserVerificationis not set explicitly.
New features:
- Method
getAaguid()added toRegistrationResult. - Method
getAttestationTrustPath()added toRegistrationResult. - Setting
.clock(Clock)added toRelyingParty. It is used for attestation path validation if anattestationTrustSourceis configured.
webauthn-server-attestation:
Breaking changes:
- Types
AttestationResolver,CompositeAttestationResolver,CompositeTrustResolver,DeviceMatcher,ExtensionMatcher,FingerprintMatcher,MetadataObject,SimpleAttestationResolver,SimpleTrustResolver,StandardMetadataServiceandTrustResolverdeleted in favour of a new attestation metadata framework. Some of the functionality is retained as the newYubicoJsonMetadataServiceclass in thewebauthn-server-demosubproject in the library sources, but no longer exposed in either library module. - Library no longer contains a
/metadata.jsonresource.
New features:
- New types
FidoMetadataServiceandFidoMetadataDownloaderwhich integrate with the FIDO Metadata Service for retrieving authenticator metadata and attestation trust roots.
Artifacts built with openjdk 11.0.15 2022-04-19.
NOTICE: Psychic signatures in Java
In April 2022, a vulnerability was disclosed in Oracle's OpenJDK (and other JVMs derived from it) which can impact applications using java-webauthn-server. The impact is that for the most common type of WebAuthn credential, invalid signatures are accepted as valid, allowing authentication bypass for users with such a credential. Please read Oracle's advisory and make sure you are not using one of the impacted OpenJDK versions. If you are, we urge you to upgrade your Java deployment to a version that is safe.