Re-authentication
Re-authentication confirms the acting user's identity again before selected account, credential, and two-factor authentication changes. It applies to REST API requests authenticated with a login session, including requests from the web interface, subject to the exceptions below. 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.
The Role of an Additional Confirmation
A browser session makes routine work practical without repeatedly entering credentials. Page content can also cause the browser to submit a request the person did not intend, such as through a script added to the page without their approval or a misleading click on a page displayed inside another page. Such a request can use the existing session without having the person's password or 2FA response. Requiring that additional verification before changing a password, recovery email address, or second factor prevents those requests from changing account access based only on the browser's session.
The web interface is itself a REST API client. The API cannot distinguish a request initiated by the person from one submitted by page content using the same session, so the confirmation requirement applies to login-session requests for the operations below, subject to the authentication exceptions.
This is not a second approval by another administrator. It confirms the acting user and leaves their existing permissions in force. A delegated administrator who passes the check can still make only the changes their permissions allow. Conversely, re-authentication does not make broad administrative access narrow; the delegation decision determines which account changes that person is trusted to make.
Re-authentication does not prevent someone who holds the session credential itself from making these changes through the Remote MCP Server. Its tool calls are exempt from the additional confirmation. Session expiration and access revocation control how long that credential remains usable and how to end its access.
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.
When re-authentication is required, 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 are exempt from the X-Files-Reauthentication header requirement. This exemption applies to every operation listed above; the key's permissions and the operation's authorization requirements still apply.
Tool calls through the Remote MCP Server are also exempt for every operation listed above, regardless of whether the login session came from Sign In with Files.com or was created through the REST API. An MCP connection lets an approved AI application act for the user rather than submitting actions through a browser page. MCP tool calls have no way to request a password or 2FA response partway through an operation, so requiring that confirmation would prevent authorized account administration through the client. The acting account's permissions still determine which changes it can make.
Requests authenticated as the site rather than an individual user also satisfy this control without a user confirmation. These connections use independent credentials, allowing authorized integrations to operate without an interactive password or 2FA prompt. Being a Site Administrator does not by itself satisfy re-authentication for a REST API request authenticated with a login session.
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.