Multi-Factor Authentication in ASP.NET Core Without Identity: Feasibility for Custom User Models

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Hello,

I would like to know if it’s possible to implement multi-factor authentication (MFA) in ASP.NET Core without using Identity.

I have a multi-tenant application with internal users (employees) and external users (clients), each with their own authentication and permission rules. Due to the complexity of the project, I’m using a custom DbContext, and I would like to understand if it’s possible to follow the MFA setup from the tutorials:

https://learn.microsoft.com/en-us/aspnet/core/security/authentication/mfa?view=aspnetcore-8.0
https://learn.microsoft.com/en-us/aspnet/identity/overview/features-api/two-factor-authentication-using-sms-and-email-with-aspnet-identity?source=recommendations

and apply it to any custom user and permission classes.

My main question is: can I adapt these MFA configurations to my custom user model, adjusting the user tables and permissions as needed, or is only Identity is required for this functionality?

Thanks!

---

Original Comments

Feedback Bot on 10/24/2024, 02:06 AM:

Thank you for taking the time to provide your suggestion. We will do some preliminary checks to make sure we can proceed further. You will hear from us in about a week on our next steps.

[MackinnonBuck]

Thanks for reaching out. We don't have first-class support for this scenario, but it can be done with enough code.

Moving to discussions so the community can help out.

[rodri-oliveira-dev]

Yes, MFA can be implemented without ASP.NET Core Identity.

I think there are actually two separate decisions here:

1. whether you want to use ASP.NET Core Identity as the authentication infrastructure;
2. whether you want to use Identity's default persistence model.

A custom DbContext, custom user entities, or even a completely different persistence mechanism does not necessarily mean you have to abandon Identity. Identity is designed around managers and stores, and the persistence layer can be replaced with custom implementations.

For example, if the main concern is keeping your existing user model and tables, you can implement the relevant store interfaces for your model, including IUserTwoFactorStore<TUser>, and still reuse UserManager, SignInManager, token providers, lockout handling, recovery codes, etc.

On the other hand, if you intentionally do not want to use Identity at all, MFA is still perfectly feasible. MFA is fundamentally an authentication workflow, not something inherently coupled to Identity.

A simplified flow would be:

Username/password
        |
        v
Primary authentication succeeds
        |
        v
Does this user require MFA?
       / \
     no   yes
     |      |
     |      v
     |   Issue MFA challenge
     |      |
     |      v
     |   Validate second factor
     |      |
     +------+
        |
        v
Issue final authenticated session/token

The important part is that I would not issue the final authenticated session after the first factor and then try to "upgrade" it informally.

I would represent the intermediate authentication state explicitly. For example, after validating the password, create a short-lived MFA challenge containing only enough information to continue the authentication flow:

public sealed record MfaChallenge(
    Guid ChallengeId,
    Guid UserId,
    Guid TenantId,
    DateTimeOffset ExpiresAt);

Then validate the second factor against that challenge before issuing the actual authentication cookie or access token.

For TOTP, the user record (or preferably a separate authentication-factor aggregate/table) would contain information such as:

UserId
TenantId
FactorType
Secret / CredentialId
Enabled
CreatedAt
LastUsedAt

In a multi-tenant system I would make the tenant part of the authentication context explicitly. I would not resolve the tenant from data supplied only after the first factor, because the MFA credential should be validated against the same tenant/user identity established during the primary authentication step.

I would also keep MFA completely separate from authorization.

Internal employees and external clients may have different:

• authentication policies;
• required MFA methods;
• session lifetimes;
• authorization rules;
• permission models.

But once authentication succeeds, authorization should still be expressed through claims/policies/permissions rather than through MFA itself.

Something like:

Authentication
 ├── Employee authentication policy
 │    └── MFA required
 │
 └── Customer authentication policy
      └── MFA conditional/required

             ↓

        ClaimsPrincipal

             ↓

Authorization policies / permissions

There are also several security concerns that become your responsibility if you implement this without Identity:

• TOTP secret generation and secure storage;
• replay protection where applicable;
• challenge expiration;
• brute-force/rate limiting;
• account lockout;
• recovery codes;
• factor enrollment and removal;
• recovery flows;
• remembered/trusted devices;
• security events and auditing;
• invalidating existing sessions after sensitive authentication changes.

Because of that, for employees I would strongly consider delegating authentication and MFA to an external identity provider through OpenID Connect rather than implementing MFA locally. For customer identities, the decision depends more on the application's requirements.

Also, I would prefer authenticator apps/TOTP, passkeys/WebAuthn, or an external identity provider over SMS as the primary MFA mechanism where possible.

So, in short:

No, ASP.NET Core Identity is not technically required for MFA.

But if the only reason for avoiding Identity is that you already have custom user tables and a custom DbContext, I would first evaluate a custom Identity store. That allows you to preserve your domain/persistence model while reusing a significant amount of security-sensitive authentication infrastructure.

If Identity is intentionally outside the architecture, then implementing MFA as a separate authentication workflow is completely valid, but at that point the application owns the full lifecycle and security guarantees of that workflow.