--- title: "Configuration" manual: "Passkeys Backend Authentication" version: "1.0" permalink: "https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:configuration@1.0" source: "Configuration/Index.rst" rendered: "2026-09-20T16:07:13+00:00" --- # Configuration {#configuration} All settings are managed through the TYPO3 Extension Configuration module: **Admin Tools > Settings > Extension Configuration > nr_passkeys_be** ![TYPO3 Extension Configuration screen for nr_passkeys_be showing all available settings](../Images/Configuration/ExtensionSettings.png) ## Relying Party settings {#relying-party-settings} - **rpId** - *type:* string - *Default:* *(auto-detected from HTTP_HOST)* The Relying Party identifier. This is typically the domain name of your TYPO3 installation (e.g. `example.com`). If left empty, it is auto-detected from the `HTTP_HOST` server variable. > [!IMPORTANT] > Once passkeys are registered against a specific `rpId`, changing it > will invalidate all existing registrations. Users would need to register > new passkeys. - **rpName** - *type:* string - *Default:* `TYPO3 Backend` A human-readable name for the Relying Party. This is displayed to users during passkey registration (e.g. in the browser's passkey creation dialog). - **origin** - *type:* string - *Default:* *(auto-detected)* The expected origin for WebAuthn operations (e.g. `https://example.com`). If left empty, it is auto-detected from the current request scheme and host. ## Challenge settings {#challenge-settings} - **challengeTtlSeconds** - *type:* int - *Default:* `120` The time-to-live for challenge tokens in seconds. After this period, the challenge expires and the user must request a new one. The default of 120 seconds provides enough time for users to interact with their authenticator. ## Discoverable login {#discoverable-login} - **discoverableLoginEnabled** - *type:* bool - *Default:* `true` Enable discoverable (identifierless) login. When enabled (default), the browser can suggest available passkeys without the user entering a username first (Conditional UI / Variant B). The user simply clicks a suggested passkey from the browser's autofill dropdown. When disabled, users must enter their username first, then authenticate with their passkey (Variant A: username-first flow). ## Password login control {#password-login-control} - **disablePasswordLogin** - *type:* bool - *Default:* `false` Enforce passkey-only authentication on a per-user basis. When enabled, password login is blocked **only for users who have registered at least one passkey**. Users without passkeys can still log in with a password, allowing gradual migration without lockouts. This enables a smooth onboarding workflow: 1. Admin creates a new backend user with a password (as usual). 1. User logs in with password, registers a passkey in User Settings. 1. From that point on, the user must use their passkey -- password login is no longer accepted for that account. When this setting is active, users cannot remove their last passkey to prevent locking themselves out. > [!NOTE] > **See also** > > For more granular per-group enforcement with grace periods, see > [Passkey Enforcement](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:enforcement@1.0). - **skipMfaOnPasskeyAuth** - *type:* bool - *Default:* `true` Added to resolve the MFA-policy dilemma: TYPO3's requireMfa flag applies to every authentication path, so requiring MFA for password users forced passkey users through a redundant TOTP step as well.When enabled, the TYPO3 MFA challenge is skipped after a successful passkey authentication. A passkey is already multi-factor -- possession of the authenticator plus biometric or PIN user verification -- so an additional TOTP prompt adds friction without increasing assurance. Password-based logins are **not** affected: they continue to go through the MFA challenge exactly as TYPO3 configures it. This setting only short-circuits the MFA step on the passkey branch. Recommended production combination (see [Passkey Enforcement](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:enforcement@1.0) for details): 1. Keep TYPO3's `$GLOBALS['TYPO3_CONF_VARS']['BE']['requireMfa']` enabled so password-based logins still require a second factor. 1. Leave `skipMfaOnPasskeyAuth` enabled so passkey users are not double-prompted. 1. Use per-group enforcement to move users onto passkeys. 1. Once adoption is high enough, enable [disablePasswordLogin](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:confval-disablepasswordlogin@1.0) to close the password fallback. Disable this setting only if your security policy explicitly mandates defence-in-depth with independent factors regardless of the primary factor's strength, or if a compliance standard you are bound to prescribes a separate MFA step. ## Rate limiting {#rate-limiting} - **rateLimitMaxAttempts** - *type:* int - *Default:* `10` Maximum number of requests allowed per IP address per endpoint within the rate limit window. Exceeding this limit returns HTTP 429 (Too Many Requests). - **rateLimitWindowSeconds** - *type:* int - *Default:* `300` Duration of the rate limiting window in seconds. The attempt counter resets after this period. ## Account lockout {#account-lockout} - **lockoutThreshold** - *type:* int - *Default:* `5` Number of consecutive failed authentication attempts before the account is temporarily locked. Applies per username/IP combination. - **lockoutUserThreshold** - *type:* int - *Default:* `15` Total number of failed authentication attempts across all IP addresses before the account is locked. This threshold should be higher than [lockoutThreshold](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:confval-lockoutthreshold@1.0) to catch distributed brute force attacks where requests come from many different IP addresses. - **lockoutDurationSeconds** - *type:* int - *Default:* `900` Duration of the account lockout in seconds (default: 15 minutes). After this period the lockout expires automatically. Administrators can also manually unlock accounts via the admin API. ## Cryptographic algorithms {#cryptographic-algorithms} - **allowedAlgorithms** - *type:* string - *Default:* `ES256` Comma-separated list of allowed signing algorithms for passkey registration. Supported values: - `ES256` -- ECDSA with SHA-256 (recommended, widely supported) - `ES384` -- ECDSA with SHA-384 - `ES512` -- ECDSA with SHA-512 - `RS256` -- RSA with SHA-256 Example for multiple algorithms: `ES256,RS256` ## User verification {#user-verification} - **userVerification** - *type:* string - *Default:* `required` The user verification requirement for WebAuthn ceremonies. Valid values: - `required` -- The authenticator must verify the user (e.g. biometric or PIN). This is the most secure option. - `preferred` -- The authenticator should verify the user if possible, but authentication proceeds even without verification. - `discouraged` -- The authenticator should not verify the user. Use this only if you want the fastest possible authentication. Invalid values fall back to `required`.