Enforcing strong authentication is critical in modern applications, but integrating multi-factor authentication (MFA) into existing identity providers can be complex and confusing. When working with Entra External ID (EEID), Microsoft's customer identity and access management solution, options to incorporate third-party MFA providers aren’t abundantly documented or straightforward.

This post walks through a practical approach to integrating a third-party MFA provider, specifically Authsignal, with EEID. Authsignal offers a flexible drop-in authentication orchestration layer, and using a Block & Redirect pattern, one can elegantly add MFA step-up authorization without modifying EEID’s core authentication. We'll break down this pattern, the technical setup, and the key implementation details for a smooth integration experience.

You’ll gain insight into how this proof-of-concept (PoC) ASP.NET Core app plugs into EEID for primary authentication and leverages Authsignal for the MFA challenge, all while preserving user experience and session integrity.

Architecture Overview

┌─────────────────────────────────────────────┐
│            Entra External ID (EEID)         │
├─────────────────────────────────────────────┤
│  • Primary user authentication using OIDC   │
│  • Identity verification and session creation│
└─────────────────────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────┐
│              ASP.NET Core App                 │
├─────────────────────────────────────────────┤
│  • Middleware intercepts authenticated calls │
│  • Blocks users who haven't completed MFA    │
│  • Redirects to Authsignal for MFA challenge │
└─────────────────────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────┐
│               Authsignal MFA Service         │
├─────────────────────────────────────────────┤
│  • Hosted MFA UI and challenge flows         │
│  • Authenticator app, OTP, recovery codes    │
│  • Provides MFA status claim on JWT          │
└─────────────────────────────────────────────┘
                     ↓
┌─────────────────────────────────────────────┐
│        Protected Application Resources        │
├─────────────────────────────────────────────┤
│  • Accessible only after MFA completion       │
│  • JWT validated for 'mfa_completed' claim   │
└─────────────────────────────────────────────┘

This layered architecture keeps authentication concerns separate: EEID confirms who the user is, while Authsignal controls if the user is authorized to proceed by verifying MFA completion.

Image: Authsignal logo from source article

Key Technical Observations

• Block & Redirect Pattern for Step-Up Authorization
  Instead of modifying EEID or its flows, the app intercepts authenticated sessions after EEID login, enforcing MFA by blocking access until the second factor completes. This non-intrusive pattern requires no changes to the identity provider itself.

• Leveraging ASP.NET Core Middleware
  A custom AuthsignalMfaMiddleware inspects every incoming authenticated request. If the request lacks a mfa_completed claim, it redirects to the MFA UI, cleanly gating resources without displaying generic errors.

• Standard OpenID Connect with Microsoft.Identity.Web
  By utilizing AddMicrosoftIdentityWebApp() from the Microsoft.Identity.Web package, the app sets up OIDC authentication against EEID with minimal effort. This abstracts token validation, OIDC metadata discovery, and cookie management into a streamlined setup.

• Claims-Based MFA Completion Status
  Authsignal adds an mfa_completed claim to the user’s JWT only after successful second-factor authentication. The app’s middleware relies on this claim to differentiate between fully authenticated users and those pending MFA, enhancing security granularity.

• PoC Focused on Sign-In Only, Extensible to Other Flows
  This proof of concept only integrates MFA on sign-in. The approach can extend to sign-up and self-service password reset (SSPR) flows, potentially by using EEID native authentication as the starting point.

• SDK & Hosted UI Facilitate Rapid Integration
  Using Authsignal’s C# SDK and pre-built MFA UI offloads complexity from the application code, speeding development and reducing maintenance overhead.

How It Works

Primary Login via Entra External ID

The user initiates login through the EEID authentication endpoint, managed internally with OpenID Connect and Azure AD protocols. The ASP.NET Core app consumes tokens using Microsoft.Identity.Web and trusts EEID for user identity verification.

builder.Services.AddMicrosoftIdentityWebApp(configuration.GetSection("EntraExternalId"));

This call sets up OIDC and cookie middleware, including automatic challenge redirects, token validation, and claims population.

The Block & Redirect Pattern Middleware

After user authentication, every incoming request hits the custom AuthsignalMfaMiddleware. The middleware logic is essentially:

if (User.Identity.IsAuthenticated)
{
    var mfaClaim = User.Claims.FirstOrDefault(c => c.Type == "mfa_completed");
    if (mfaClaim == null || mfaClaim.Value != "true")
    {
        // Redirect to MFA challenge page
        context.Response.Redirect($"/mfa/challenge?returnUrl={originalUrl}");
        return;
    }
}
await _next(context);

Blocking requests upfront ensures the user cannot access protected resources without completing MFA — the challenge is always enforced gracefully.

MFA Challenge and Completion with Authsignal

The /mfa/challenge endpoint redirects the user to the Authsignal-hosted MFA UI. This UI supports multiple authenticators such as authenticator apps, SMS codes, or hardware keys.

Once the user successfully completes MFA, Authsignal returns control to /mfa/callback in the app, where the middleware marks the user's session with the mfa_completed claim via token issuance or session update.

This claim is then validated in subsequent requests to allow access.

Preserving User Experience with Return URLs

The original destination URL is preserved as a returnUrl parameter across redirects, ensuring the user lands where intended after MFA without confusing navigation disruptions.

---

Example appsettings.json Excerpt

{
  "EntraExternalId": {
    "Authority": "https://eeid-tenant.ciamlogin.com/b7...aa/v2.0",
    "ClientId": "88...28",
    "ClientSecret": "Uy...ha",
    "CallbackPath": "/signin-oidc",
    "ResponseType": "code",
    "Scope": [ "openid", "profile", "email" ]
  },
  "Authsignal": {
    "TenantId": "blah",
    "SecretKey": "EQ...zA==",
    "BaseUrl": "https://au.api.authsignal.com/v1"
  }
}

This configuration wires the app to EEID for OIDC authentication and Authsignal for MFA REST API calls.

Quick Tips & Tricks

1. Use Claims to Track MFA Completion
   Embedding an mfa_completed claim in the JWT allows straightforward authorization gating in middleware without needing to maintain separate session state.

2. Keep MFA and Primary Authentication Separate
   Using the Block & Redirect pattern decouples authentication from MFA policies, so you can swap out MFA providers with minimal changes on the identity side.

3. Leverage Managed SDKs for MFA Integration
   Using Authsignal’s C# SDK reduces boilerplate and error-prone code — leverage official SDKs wherever available for production integrations.

4. Configure EEID App Registration Correctly
   Ensure your EEID app is registered for web app OIDC flows with correct redirect URIs such as /signin-oidc and proper logout callbacks to maintain session hygiene.

5. Preserve Return URLs After MFA
   Always forward original URLs through MFA redirects to avoid user confusion and maintain seamless navigation.

6. Build Modular Middleware
   Implement MFA middleware as a loosely coupled module to keep your authentication pipeline flexible and maintainable.

Conclusion

Integrating third-party MFA into Entra External ID can be streamlined effectively through a Block & Redirect approach that preserves separation of concerns between authentication and step-up authorization. Using Authsignal’s hosted MFA UI and SDK makes the effort lightweight while maintaining robust security controls.

This setup is an excellent base for extending MFA integration across sign-in, sign-up, and password reset flows. As authentication ecosystems evolve, embracing modular, standards-compliant architectures like this will remain essential for scalable, secure identity management.

With growing demand for flexible customer identity and access management, coupling EEID with adaptable MFA providers like Authsignal offers a practical path to balancing security and usability in modern apps.

References

1. Integrating Entra External ID (EEID) with a third-party MFA provider, e.g. Authsignal — Original in-depth integration walkthrough by Rory Braybrook
2. Authsignal Documentation — Official SDKs and MFA implementation options
3. Microsoft.Identity.Web GitHub — High-level libraries for integrating Microsoft identity platform in ASP.NET apps
4. Entra External ID Official Documentation — Microsoft’s customer identity service guidance
5. Block and Redirect Pattern Gist — Source code example for the MFA flow

---

Authored by Rory Braybrook