Package io.quarkus.security.webauthn

Interface WebAuthnRunTimeConfig

@ConfigMapping(prefix="quarkus.webauthn") @ConfigRoot(phase=RUN_TIME) public interface WebAuthnRunTimeConfig
Webauthn runtime configuration object.

  • Method Details

    • origin

      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

      @ConfigDocDefault("USB,NFC,BLE,INTERNAL") 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

      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

      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

      @ConfigDocDefault("false") 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

      @ConfigDocDefault("DISCOURAGED") 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

      @ConfigDocDefault("60s") 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

      @ConfigDocDefault("NONE") 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

      @ConfigDocDefault("ES256,RS256") 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.

    • challengeLength

      @ConfigDocDefault("64") OptionalInt challengeLength()
      Length of the challenges exchanged between the application and the browser. Challenges must be at least 32 bytes.

    • loginPage

      @WithDefault("/login.html") String loginPage()
      The login page

    • sessionTimeout

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

    • newCookieInterval

      @WithDefault("PT1M") 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 because 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 user's last request is when the cookie is 9m old then the actual timeout will happen 21m after the last request because the timeout is only refreshed when a new cookie is generated. That is, 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.

    • cookieName

      @WithDefault("quarkus-credential") String cookieName()
      The cookie that is used to store the persistent session

    • challengeCookieName

      @WithDefault("_quarkus_webauthn_challenge") String challengeCookieName()
      The cookie that is used to store the challenge data during login/registration

    • challengeUsernameCookieName

      @WithDefault("_quarkus_webauthn_username") String challengeUsernameCookieName()
      The cookie that is used to store the username data during login/registration

    • cookieSameSite

      @WithDefault("strict") WebAuthnRunTimeConfig.CookieSameSite cookieSameSite()
      SameSite attribute for the session cookie.

    • cookiePath

      @WithDefault("/") Optional<String> cookiePath()
      The cookie path for the session cookies.

    • cookieMaxAge

      Optional<Duration> cookieMaxAge()
      Max-Age attribute for the session cookie. This is the amount of time the browser will keep the cookie. The default value is empty, which means the cookie will be kept until the browser is closed.