✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

Greptile Summary

This PR adds isMfaEnabled and mfaMethod fields to the /token-exchange SSO route response so that clients can correctly redirect to the MFA step when using the OAuth token exchange flow. The intent is correct, but the implementation contains a field-access bug that would break org-enforced MFA.

• Bug: isMfaEnabled: data.user.isMfaEnabled reads the user's personal MFA flag from the database record (userEnc). The service's oauth2TokenExchange sets the top-level data.isMfaEnabled = true whenever either the org enforces MFA or the user has personal MFA enabled. When an organisation has enforceMfa = true but the individual user does not have personal MFA turned on, data.user.isMfaEnabled is false while data.isMfaEnabled is true — the client would skip MFA and misuse the issued MFA token as a regular access token.
• The correct fix is to use data.isMfaEnabled (the top-level computed flag), not data.user.isMfaEnabled.
• mfaMethod: data?.mfaMethod is correct — mfaMethod lives at the top level of the service return.

Confidence Score: 2/5

• Not safe to merge as-is — org-enforced MFA silently breaks in the token-exchange flow.
• The one-line fix has the correct structure, but reads the wrong field. Using data.user.isMfaEnabled instead of data.isMfaEnabled means that any organisation using enforced MFA (where the individual user has not personally enabled MFA) will receive isMfaEnabled: false even though the token returned is an MFA token, breaking that authentication path.
• backend/src/server/routes/v1/sso-router.ts — line 632 must use data.isMfaEnabled instead of data.user.isMfaEnabled.

Important Files Changed

_{Reviews (1): Last reviewed commit: "feat: resolved mfa error in token exchan..." | Re-trigger Greptile}