Package io.quarkus.security.webauthn

Class WebAuthnRunTimeConfig

    • Field Detail

      • origin

        @ConfigItem
public Optional<String> origin
        The origin of the application. The origin is basically protocol, host and port. If you are calling WebAuthn API while your application is located at https://example.com/login, then origin will be https://example.com. If you are calling from http://localhost:2823/test, then the origin will be http://localhost:2823. Please note that WebAuthn API will not work on pages loaded over HTTP, unless it is localhost, which is considered secure context.

      • transports

        @ConfigItem(defaultValueDocumentation="USB,NFC,BLE,INTERNAL")
public Optional<List<io.vertx.ext.auth.webauthn.AuthenticatorTransport>> transports
        Authenticator Transports allowed by the application. Authenticators can interact with the user web browser through several transports. Applications may want to restrict the transport protocols for extra security hardening reasons. By default, all transports should be allowed. If your application is to be used by mobile phone users, you may want to restrict only the INTERNAL authenticator to be allowed. Permitted values are:
        • USB - USB connected authenticators (e.g.: Yubikey's)
        • NFC - NFC connected authenticators (e.g.: Yubikey's)
        • BLE - Bluetooth LE connected authenticators
        • INTERNAL - Hardware security chips (e.g.: Intel TPM2.0)

      • relyingParty

        @ConfigItem
public WebAuthnRunTimeConfig.RelyingPartyConfig relyingParty
        Your application is a relying party. In order for the user browser to correctly present you to the user, basic information should be provided that will be presented during the user verification popup messages.

      • authenticatorAttachment

        @ConfigItem
public Optional<io.vertx.ext.auth.webauthn.AuthenticatorAttachment> authenticatorAttachment
        Kind of Authenticator Attachment allowed. Authenticators can connect to your device in two forms:
        • PLATFORM - The Authenticator is built-in to your device (e.g.: Security chip)
        • CROSS_PLATFORM - The Authenticator can roam across devices (e.g.: USB Authenticator)
        For security reasons your application may choose to restrict to a specific attachment mode. If omitted, then any mode is permitted.

      • requireResidentKey

        @ConfigItem(defaultValueDocumentation="false")
public Optional<Boolean> requireResidentKey
        Resident key required. A resident (private) key, is a key that cannot leave your authenticator device, this means that you cannot reuse the authenticator to log into a second computer.

      • userVerification

        @ConfigItem(defaultValueDocumentation="REQUIRED")
public Optional<io.vertx.ext.auth.webauthn.UserVerification> userVerification
        User Verification requirements. Webauthn applications may choose REQUIRED verification to assert that the user is present during the authentication ceremonies, but in some cases, applications may want to reduce the interactions with the user, i.e.: prevent the use of pop-ups. Valid values are:
        • REQUIRED - User must always interact with the browser
        • PREFERRED - User should always interact with the browser
        • DISCOURAGED - User should avoid interact with the browser

      • timeout

        @ConfigItem(defaultValueDocumentation="60s")
public Optional<Duration> timeout
        Non-negative User Verification timeout. Authentication must occur within the timeout, this will prevent the user browser from being blocked with a pop-up required user verification, and the whole ceremony must be completed within the timeout period. After the timeout, any previously issued challenge is automatically invalidated.

      • attestation

        @ConfigItem(defaultValueDocumentation="NONE")
public Optional<io.vertx.ext.auth.webauthn.Attestation> attestation
        Device Attestation Preference. During registration, applications may want to attest the device. Attestation is a cryptographic verification of the authenticator hardware. Attestation implies that the privacy of the users may be exposed and browsers might override the desired configuration on the user's behalf. Valid values are:
        • NONE - no attestation data is sent with registration
        • INDIRECT - attestation data is sent with registration, yielding anonymized data by a trusted CA
        • DIRECT - attestation data is sent with registration
        • ENTERPRISE - no attestation data is sent with registration. The device AAGUID is returned unaltered.

      • pubKeyCredParams

        @ConfigItem(defaultValueDocumentation="ES256,RS256")
public Optional<List<io.vertx.ext.auth.webauthn.PublicKeyCredential>> pubKeyCredParams
        Allowed Public Key Credential algorithms by preference order. Webauthn mandates that all authenticators must support at least the following 2 algorithms: ES256 and RS256. Applications may require stronger keys and algorithms, for example: ES512 or EdDSA. Note that the use of stronger algorithms, e.g.: EdDSA may require Java 15 or a cryptographic JCE provider that implements the algorithms.

      • sessionTimeout

        @ConfigItem(defaultValue="PT30M")
public Duration sessionTimeout
        The inactivity (idle) timeout When inactivity timeout is reached, cookie is not renewed and a new login is enforced.

      • newCookieInterval

        @ConfigItem(defaultValue="PT1M")
public Duration newCookieInterval
        How old a cookie can get before it will be replaced with a new cookie with an updated timeout, also referred to as "renewal-timeout". Note that smaller values will result in slightly more server load (as new encrypted cookies will be generated more often), however larger values affect the inactivity timeout as the timeout is set when a cookie is generated. For example if this is set to 10 minutes, and the inactivity timeout is 30m, if a users last request is when the cookie is 9m old then the actual timeout will happen 21m after the last request, as the timeout is only refreshed when a new cookie is generated. In other words, no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie itself, and it is decrypted and parsed with each request.

    • Constructor Detail

      • WebAuthnRunTimeConfig

        public WebAuthnRunTimeConfig()