Email TFA 2.0.6: /user/login API always forbidden when TFA is enabled. Should it respect Email TFA settings?

Problem/Motivation

In version 2.0.6, a significant update was introduced:

Attempts to log in through the user.login.http route (POST /user/login) while Email TFA is enabled now return an AccessDeniedHttpException (HTTP 403 Forbidden) with the following message:

"Two-factor authentication is enabled. REST API login is not supported. Please use the standard login form at /user/login."

While I understand that this measure was implemented to eliminate the security gap reported in SA-CONTRIB-2025-115, it can be perceived as a very restrictive behavior.

Why this is a problematic scenario

This change can significantly affect decoupled architectures and integrations that rely on the POST /user/login endpoint, including scenarios where credentials are used for users who are legitimately excluded from Email TFA (when Pathway is globally_enabled) or whose individual accounts do not have Email TFA enabled (when Pathway is optionally_by_users). Under the current implementation, any third-party application, frontend, or automated process that depends on this endpoint for authentication will fail outright when Email TFA is enabled, without taking the module’s role- or user-based settings into account.

This behavior may force widespread refactoring of existing external applications, requiring teams to migrate to alternative authentication mechanisms such as JWT, OAuth, or similar solutions. While these approaches may be more appropriate in the long term, introducing such a breaking change increases operational and development overhead—particularly for projects that were previously functioning as intended.

Proposed resolution

That said, a more flexible approach - based on the module's configuration options (Pathway, Exclude roles, Roles, etc) - could potentially have been implemented. For example:

• If a user attempts to authenticate via the POST /user/login API while Email TFA is enabled:
  • Based on the user name provided in the request body, load the corresponding user account.
  • Call checkTwoFactorAuthentication() to determine whether the user must undergo the two-factor authentication process.
    • Yes → return a Forbidden response
    • No → continue with the authentication process

This approach would ensure that users who legitimately have roles exempt from Email TFA (when Pathway is globally_enabled), as well as users who have not enabled Email TFA on their accounts (when Pathway is optionally_by_users), can still authenticate successfully via this endpoint, while preserving the intended security guarantees for all other users.

What are your thoughts on this proposal?

Remaining tasks

Discuss the proposed approach and, if any adjustments are agreed upon, implement them.
Review the MR and continue discussion.

User interface changes

None.

API changes

None.

Data model changes

None.