io.quarkus.security.webauthn.WebAuthnRunTimeConfig.jdp Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of quarkus-security-webauthn Show documentation
Show all versions of quarkus-security-webauthn Show documentation
Secure your applications with WebAuthn
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.attestation=Device Attestation Preference. During registration, applications may want to attest the device. Attestation is a\ncryptographic verification of the authenticator hardware.\n\nAttestation implies that the privacy of the users may be exposed and browsers might override the desired\nconfiguration on the user's behalf.\n\nValid values are\:\n\n\n- {@code NONE} - no attestation data is sent with registration
\n- {@code INDIRECT} - attestation data is sent with registration, yielding anonymized data by a trusted\nCA
\n- {@code DIRECT} - attestation data is sent with registration
\n- {@code ENTERPRISE} - no attestation data is sent with registration. The device AAGUID is returned\nunaltered.
\n
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.authenticatorAttachment=Kind of Authenticator Attachment allowed. Authenticators can connect to your device in two forms\:\n\n\n- {@code PLATFORM} - The Authenticator is built-in to your device (e.g.\: Security chip)
\n- {@code CROSS_PLATFORM} - The Authenticator can roam across devices (e.g.\: USB Authenticator)
\n
\n\nFor security reasons your application may choose to restrict to a specific attachment mode. If omitted, then\nany mode is permitted.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.challengeCookieName=The cookie that is used to store the challenge data during login/registration
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.challengeLength=Length of the challenges exchanged between the application and the browser.\nChallenges must be at least 32 bytes.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.challengeUsernameCookieName=The cookie that is used to store the username data during login/registration
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.cookieName=The cookie that is used to store the persistent session
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.cookiePath=The cookie path for the session cookies.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.cookieSameSite=SameSite attribute for the session cookie.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.loginPage=The login page
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.newCookieInterval=How old a cookie can get before it will be replaced with a new cookie with an updated timeout, also\nreferred to as "renewal-timeout".\n\nNote that smaller values will result in slightly more server load (as new encrypted cookies will be\ngenerated more often); however, larger values affect the inactivity timeout because the timeout is set\nwhen a cookie is generated.\n\nFor example if this is set to 10 minutes, and the inactivity timeout is 30m, if a user's last request\nis when the cookie is 9m old then the actual timeout will happen 21m after the last request because the timeout\nis only refreshed when a new cookie is generated.\n\nThat is, no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie\nitself, and it is decrypted and parsed with each request.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.origin=The origin of the application. The origin is basically protocol, host and port.\n\nIf you are calling WebAuthn API while your application is located at {@code https\://example.com/login},\nthen origin will be {@code https\://example.com}.\n\nIf you are calling from {@code http\://localhost\:2823/test}, then the origin will be\n{@code http\://localhost\:2823}.\n\nPlease note that WebAuthn API will not work on pages loaded over HTTP, unless it is localhost,\nwhich is considered secure context.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.pubKeyCredParams=Allowed Public Key Credential algorithms by preference order. Webauthn mandates that all authenticators must\nsupport at least the following 2 algorithms\: {@code ES256} and {@code RS256}.\n\nApplications may require stronger keys and algorithms, for example\: {@code ES512} or {@code EdDSA}.\n\nNote that the use of stronger algorithms, e.g.\: {@code EdDSA} may require Java 15 or a cryptographic {@code JCE}\nprovider that implements the algorithms.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.relyingParty=Your application is a relying party. In order for the user browser to correctly present you to the user, basic\ninformation should be provided that will be presented during the user verification popup messages.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.requireResidentKey=Resident key required. A resident (private) key, is a key that cannot leave your authenticator device, this\nmeans that you cannot reuse the authenticator to log into a second computer.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.sessionTimeout=The inactivity (idle) timeout\n\nWhen inactivity timeout is reached, cookie is not renewed and a new login is enforced.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.timeout=Non-negative User Verification timeout. Authentication must occur within the timeout, this will prevent the user\nbrowser from being blocked with a pop-up required user verification, and the whole ceremony must be completed\nwithin the timeout period. After the timeout, any previously issued challenge is automatically invalidated.
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.transports=Authenticator Transports allowed by the application. Authenticators can interact with the user web browser\nthrough several transports. Applications may want to restrict the transport protocols for extra security\nhardening reasons.\n\nBy default, all transports should be allowed. If your application is to be used by mobile phone users,\nyou may want to restrict only the {@code INTERNAL} authenticator to be allowed.\n\nPermitted values are\:\n\n\n- {@code USB} - USB connected authenticators (e.g.\: Yubikey's)
\n- {@code NFC} - NFC connected authenticators (e.g.\: Yubikey's)
\n- {@code BLE} - Bluetooth LE connected authenticators
\n- {@code INTERNAL} - Hardware security chips (e.g.\: Intel TPM2.0)
\n
io.quarkus.security.webauthn.WebAuthnRunTimeConfig.userVerification=User Verification requirements. Webauthn applications may choose {@code REQUIRED} verification to assert that\nthe user is present during the authentication ceremonies, but in some cases, applications may want to reduce the\ninteractions with the user, i.e.\: prevent the use of pop-ups. Valid values are\:\n\n\n- {@code REQUIRED} - User must always interact with the browser
\n- {@code PREFERRED} - User should always interact with the browser
\n- {@code DISCOURAGED} - User should avoid interact with the browser
\n