Table of contents
Implementing multi-factor authentication for an existing web app depends on what the application already supports and how much of its login experience you want to change.
There are four practical approaches: use the application's native MFA or SSO capability, add an SDK or API integration, require authentication through an IdP-backed proxy, or use Datawiza's no-code MFA with the existing application login.
For employee applications, customer portals, and partner portals, the decision comes down to a few questions: Can you change the source code? Do you want users to authenticate through an identity provider? Can you preserve their current accounts and login experience?
These are implementation patterns, not exclusive vendor categories. A product may support more than one. Start with the application's capabilities and the experience you want users to have.
1. Use the application's native MFA or SAML/OIDC SSO
First, check whether the application already has an MFA feature. If its methods, policies, and recovery options meet your requirements, enabling that feature may be the most direct route.
Native MFA flow: Application login → application MFA → protected access.
Alternatively, the application may already support SAML or OpenID Connect (OIDC) single sign-on. You can configure that integration with an identity provider and require MFA through the provider's authentication policy.
Federated flow: IdP sign-in and required MFA → application accepts the sign-in response → protected access.
SSO support alone does not mean MFA is enforced. Confirm that the policy covers the correct application and users, that accounts map correctly, and that another login path cannot bypass the requirement. Also check whether the application's license includes the necessary MFA or SSO capability.
When this fits: The application already provides the capabilities you need, and the resulting login experience works for its users.
2. Add MFA through application code, SDKs, or APIs
If you control the source code, developers can integrate an authentication platform or verification service into the application. Examples include:
- Amazon Cognito: Integrate user authentication through managed login, OIDC libraries, AWS Amplify, or SDKs. Cognito integration documentation.
- Microsoft Entra External ID: Integrate customer sign-in and configure an MFA policy for the application. External ID MFA documentation.
- Auth0: Use the appropriate SDK to connect the application to Auth0, then configure its authentication and MFA behavior. Auth0 SDK libraries.
- Twilio Verify: Add verification challenges to an existing login flow through an API. Twilio Verify documentation.
Cognito, Entra External ID, and Auth0 can serve as the application's identity platform. Twilio Verify supplies verification functions that your application connects to its existing accounts. They do not all require the same account architecture or integration work.
Example API flow: Existing password check → verification challenge → server validates the result → protected access.
Your team must connect authentication to the correct account, handle sessions, enforce access, and maintain the integration. In a Twilio Verify implementation, for example, the application must act on the approved verification result before allowing access. Sending a code does not complete the integration. Verification Check API.
Work out whether existing accounts will be retained, connected, federated, or migrated as part of the chosen design. Migration is not an automatic requirement of every SDK or API approach.
When this fits: You control development and want authentication integrated into custom application workflows. Include implementation, testing, and ongoing maintenance in the project budget.
3. Put an IdP-backed access proxy in front of the application
An access proxy can require users to authenticate through an identity provider before allowing traffic to reach an application. This pattern is often used as part of a zero trust access design.
The user experience depends on whether the backend application can accept the authenticated identity from the proxy through a supported SSO integration.
With backend SSO: IdP sign-in and required MFA → proxy → application session → protected access.
Without backend SSO: IdP sign-in and required MFA → proxy → separate application login → protected access.
The second flow can produce a double login: one primary sign-in at the IdP and another at the application. This is different from entering a password and then completing a second factor.
A supported SSO connection can remove the additional application login. For example, Microsoft documents header-based SSO through its application proxy. The application must support and trust the selected integration; placing a proxy in front of it does not by itself replace its login.
For a customer portal that already maintains local accounts, assess the additional identity onboarding, account mapping, and possible login friction. An IdP-backed proxy can still suit customer-facing applications when its identity and SSO model fits the use case.
When this fits: Users already authenticate through a suitable IdP, or adopting that identity model is part of the project. Verify backend SSO compatibility before promising a single login experience.
4. Datawiza: An innovative approach to MFA without rebuilding your login
Datawiza adds MFA to existing web apps without changing application code, migrating user accounts, or requiring a separate identity provider, Active Directory, or LDAP. Your application continues checking users' existing credentials; Datawiza adds the second-factor challenge before protected access continues.
Keep your application. Keep your users. Add MFA.
The innovation is in how MFA fits into the application: the existing login remains responsible for primary authentication, while Datawiza enforces the additional factor. The web-app configuration guide documents this built-in MFA flow.
Built-in MFA flow: Existing application login → Datawiza MFA → protected access.
The arrows show the sign-in sequence. Application traffic passes through Datawiza Access Proxy throughout.
Users still enroll their MFA factors, and MFA records must be provisioned or created through the supported enrollment flow. Preserving application accounts does not remove enrollment and recovery work.
An IdP is optional. Datawiza can also integrate with an existing identity provider when that is the preferred design. Its MFA overview describes both built-in and IdP-based options. The backend SSO requirements depend on the selected integration.
Datawiza also uses an access proxy. The distinction here is that built-in MFA can preserve the application's primary login without introducing a separate IdP sign-in solely to add MFA.
For example, a customer portal can continue validating accounts in its existing user store. Customers use their current credentials, then complete MFA before continuing into the portal.
Prepare application routing, TLS, and MFA policy, then validate the login flow. For a hosted deployment, a DNS or routing update directs traffic through Datawiza; self-hosted deployment is also available. See the deployment options.
When this fits: An existing application needs MFA while preserving its current login and accounts, especially when source-code changes or a separate identity project would add unnecessary work.
Compare the four implementation approaches
| Approach | Application work | IdP requirement | Login experience |
|---|---|---|---|
| Native MFA or existing SAML/OIDC SSO | Configure supported application features | Optional for native MFA; required for the federated path | Native login plus MFA, or federated sign-in |
| SDK or API integration | Add or change authentication code and maintain it | Depends on the service and design | Designed and enforced by the application integration |
| Proxy preauthentication with an IdP | Configure proxy, identity mapping, and any backend SSO integration | Required for this pattern | IdP sign-in; a separate app login may remain without backend SSO |
| Datawiza built-in no-code MFA | Configure proxy routing, MFA, and enrollment; no source changes | Not required; Datawiza also supports optional IdP integration | Existing application login followed by MFA |
Turn the selected approach into a production rollout
Start with one application and inventory its users, login paths, backend endpoints, and nonbrowser clients. Confirm which protected resources must require MFA and who owns application behavior, policy, infrastructure, and support.
Choose authentication methods, session duration, and recovery procedures before the pilot. Authenticator and SMS codes are not phishing-resistant; if that is a requirement, evaluate suitable FIDO2/WebAuthn support in the selected deployment. NIST authentication guidance.
Prepare enrollment instructions and a verified process for lost devices and factor resets. Recovery must not become an easier way around authentication. See OWASP's MFA guidance.
For a proxy deployment, restrict direct access to protected backend resources so users cannot bypass the enforcement point. Datawiza's network restriction guidance gives examples.
Run these acceptance tests before expanding the rollout:
| Test | Expected outcome |
|---|---|
| Correct password without completing required MFA | Protected content remains inaccessible |
| Wrong, expired, or reused code | Access is denied and retry limits apply as configured |
| Successful MFA | The correct account receives only its existing permissions |
| Bookmarked page, alternate hostname, or direct backend | The protected resource cannot bypass the MFA requirement |
| Logout or session expiry | Access requires the intended authentication flow again |
| Lost device and approved factor reset | The legitimate user can recover access through the verified process |
| Verification service or proxy outage | New access cannot bypass required MFA; existing sessions follow the documented policy |
| API client or background job | Its separate authentication design works without an unintended exemption for browser users |
MFA does not replace application authorization. Continue checking permissions on protected requests. OWASP authorization guidance.
Pilot with a representative group, resolve login and recovery problems, and then expand. Monitor enrollment completion, failed challenges, recovery requests, and support volume. Include these operational costs when comparing approaches; the MFA cost guide provides a budgeting example.
Evaluate MFA with your current application
Bring one web app or portal and its current login flow. Book an MFA demo to see how Datawiza can add MFA while preserving existing application accounts, with built-in MFA or an IdP integration that fits your environment.
