Re-authentication
Re-authentication confirms the acting user's identity again before selected account, credential, and two-factor authentication changes. The extra check reduces reliance on an existing session for those changes. The user's permissions still determine whether the change is allowed; confirming an identity does not grant additional access. An administrator changing another user's account confirms the administrator's own identity.
The confirmation applies to one write request. It does not establish a grace period or make the session "recently re-authenticated" for later changes. Each request that requires confirmation must satisfy the check independently.
Operations That Require Confirmation
The following operations use this control, subject to the authentication exceptions below. For updates limited to particular fields, including any listed field in the request triggers the check, even if its value is unchanged. Other fields on the same operation do not trigger it.
| Operation | Scope of the re-authentication requirement |
|---|---|
Update a user: PATCH /users/{id} | Password, email address, or Site Administrator status: password, change_password, email, and site_admin. The same rule applies when updating the current user through PATCH /user. |
Delete a user: DELETE /users/{id} | The entire operation. |
Reset a user's 2FA: POST /users/{id}/2fa/reset | The entire operation. |
Update the site: PATCH /site | Contact email or the listed site-wide 2FA controls: email, require_2fa, require_2fa_exempt_all_sso_users, require_2fa_user_type, and disable_2fa_with_delay. |
Cancel the site: DELETE /site | The entire operation. |
Add a 2FA method: POST /2fa | The entire operation. |
Remove a 2FA method: DELETE /2fa/{id} | Removal of a method whose setup is complete. Removing an unfinished setup does not require this confirmation. |
Create an API key: POST /api_keys | Key creation, except when issuing a dedicated Desktop App, Mobile App, or online-editor credential. Those credentials support the app or editor connection being established. The exception concerns the credential being created. |
This is a specific set of confirmations, rather than a requirement for every administrative change. Creating an SSO provider through POST /sso_strategies, or updating a user's authentication_method or sso_strategy_id, does not itself require re-authentication. Including a listed field in the same user update does. These operations remain subject to their normal administrative permissions and account restrictions.
Verification and Authentication Exceptions
When confirmation is required, Files.com verifies an active 2FA method applicable to the acting user on the current site, such as a one-time code or a WebAuthn security-key response. Otherwise, it verifies the user's current account password. Adding a first 2FA method therefore uses the password where a password check applies; adding another method uses an existing active method.
API clients supply this verification in X-Files-Reauthentication. The compatibility header X-BRICK-REAUTHENTICATION is also accepted. Files.com evaluates the header on write requests, not on GET or HEAD requests. Supplying it on a read does not confirm a later change.
Requests authenticated with an API key satisfy this control without a separate confirmation header. Requests authenticated as the site rather than an individual user also satisfy it without a user confirmation. These connections use independent credentials, allowing authorized integrations to operate without an interactive password or 2FA prompt. The key's permissions and the operation's authorization requirements still apply. Being a Site Administrator does not by itself satisfy re-authentication.
For SSO users whose provider is not LDAP, no additional confirmation is required when the user has no active Files.com 2FA method. The same exception applies when the user's only active 2FA type is WebAuthn and it is registered on a different site, such as a parent-site user working on a child site. Files.com does not ask these users for an identity-provider password or start another identity-provider sign-in. LDAP users remain subject to the applicable password or 2FA check.
These exceptions are separate from 2FA requirements at sign-in. A site's decision to require or exempt SSO users from sign-in 2FA is not a rule that every later write must repeat that sign-in.
Failed Confirmations
A missing or incorrect confirmation prevents an operation that requires it. Three consecutive incorrect confirmations end the session, requiring a new sign-in. A successful confirmation clears that consecutive-failure count.
Rate limits restrict repeated attempts to guess a password or verification code. Successful confirmations do not consume the failed-attempt allowance, but an exhausted allowance can temporarily prevent another attempt even when the supplied verification is correct.