Modern authentication in .NET needs SSO, MFA, and passwordless

At a glance

What this is: This is a step-by-step tutorial on adding SSO, MFA, and passwordless authentication to a .NET app, with the main finding that enterprise-ready login still depends on careful callback handling, factor storage, and redirect control.

Why it matters: It matters to IAM practitioners because the same authentication choices that improve user experience also reshape trust, federation, and lifecycle governance across human identity programmes and downstream access decisions.

By the numbers:

• The authorization code is valid for 10 minutes.
• One-time-use codes expire after 10 minutes.

👉 Read WorkOS's guide to adding SSO, MFA, and passwordless to .NET

Context

Modern authentication is no longer just a front-door experience problem. In a .NET application, SSO, MFA, and passwordless login all create different trust paths, and each path needs its own handling for redirects, callback validation, factor enrolment, and session handoff.

For IAM teams, the governance question is whether those authentication patterns are aligned to the user population and the enterprise controls that sit behind them. SSO usually belongs to workforce or customer federation, MFA often belongs to the IdP rather than the app itself, and passwordless changes recovery, enrolment, and assurance assumptions.

Key questions

Q: How should security teams implement SSO in a .NET application without creating callback risk?

A: Use explicit redirect URI allowlists, validate the returned organization or tenant before issuing a session, and keep the authorization code exchange tightly scoped to the expected callback flow. The main failure mode is trusting the redirect without verifying that the authenticated identity belongs to the intended tenant or business context.

Q: Why do MFA flows need lifecycle governance instead of one-time implementation?

A: Because the factor itself becomes an identity artefact with a lifecycle. Enrolment, challenge, verification, recovery, and revocation all create state that can outlive the user intent if it is not tied to offboarding and account change events.

Q: What do teams get wrong about passwordless authentication?

A: They often assume that removing passwords removes the main risk. In practice, passwordless shifts trust to email security, code delivery, and account recovery, so the control question becomes whether those supporting channels are stronger than the password problem they replace.

Q: How do SSO, MFA, and passwordless compare as enterprise authentication options?

A: SSO centralises trust in the identity provider, MFA raises assurance by adding a second factor, and passwordless removes memorised secrets but depends heavily on the assurance of the delivery channel. The right choice depends on tenant model, recovery design, and the level of identity assurance the application needs.

Technical breakdown

SSO callback handling and redirect URI control

SSO in a .NET app works by redirecting the user to an identity provider, then receiving an authorization code on a callback endpoint. The application must validate the returned profile, tie it to the expected organization, and keep redirect URIs tightly constrained in the dashboard. The code exchange is the point where federation becomes application session state, so misbinding the callback can create cross-tenant access risk or account confusion. Practical implication: lock down redirect URIs and validate organization membership before issuing a session.

Practical implication: lock down redirect URIs and validate organization membership before issuing a session.

MFA factor enrolment, challenge, and verification

The MFA flow has three distinct stages: enrolment, challenge, and verification. The tutorial uses TOTP, where a shared secret is generated and represented as a QR code or seed, then later reused to challenge the user with a time-based code. The important design choice is where the factor lives. If the application persists the factor ID, it becomes part of the identity record and must be governed like any other credential binding. Practical implication: treat MFA factors as durable identity artefacts that require lifecycle tracking and revocation handling.

Practical implication: treat MFA factors as durable identity artefacts that require lifecycle tracking and revocation handling.

Passwordless authentication and one-time-code trust windows

Passwordless login through Magic Auth replaces memorised secrets with a short-lived code delivered by email. That reduces password risk, but it shifts trust to inbox security, code expiry, and the quality of the email delivery path. The control boundary changes again if the team builds its own UI through the API rather than using the hosted experience. Practical implication: align passwordless adoption with email assurance, recovery paths, and the blast radius of mailbox compromise.

Practical implication: align passwordless adoption with email assurance, recovery paths, and the blast radius of mailbox compromise.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSO is a federation control, not just a login feature. The tutorial shows how the application depends on the IdP for authentication, then uses callback handling to turn that external assertion into local session access. That means the security boundary is the validation logic around the redirect, organization binding, and redirect URI allowlist. Practitioners should treat federation as an identity trust chain, not as a UI convenience.

MFA becomes governance-sensitive the moment the app persists factor state. The factor ID, challenge ID, and verification result are identity artefacts that need lifecycle handling, not just code flow handling. If those records are not tied to user status, recovery, and offboarding processes, the application can preserve stale authentication bindings long after the user context changes. Practitioners should map MFA records into their access governance model.

Passwordless login shifts trust from memorised secrets to delivery channels. That changes the failure mode from password reuse to inbox compromise, code interception, and recovery weakness. The article makes clear that one-time codes are short-lived, but short-lived does not mean self-governing. Practitioners should evaluate whether their email security and account recovery controls are strong enough for the assurance level they expect.

Identity lifecycle must extend beyond directory sync into authentication artefacts. The tutorial points to Directory Sync, Admin Portal, Roles and Permissions, and Audit Logs as adjacent capabilities, which is the right architectural direction. Authentication methods become safer when they are governed as part of the broader joiner-mover-leaver model rather than as isolated implementation choices. Practitioners should connect login method choice to offboarding, recertification, and logging.

From our research:

• The authorization code is valid for 10 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: The average estimated time to remediate a leaked secret is 27 days, according to The State of Secrets in AppSec.
• Password governance and callback control become more urgent when short-lived credentials and delayed remediation collide across identity workflows.

What this signals

Code-bound trust windows are getting shorter, but governance windows are not. When authentication artefacts expire in minutes, the operational challenge shifts to whether validation, logging, and revocation keep pace with those shorter trust windows. Teams that still rely on coarse review cycles will miss failures that happen entirely between control checks.

Passwordless and SSO should be evaluated together, not as separate feature requests. One changes the federation boundary, the other changes the recovery and assurance boundary. That makes identity architecture, not individual login methods, the real design problem for product teams that expect enterprise adoption.

As authentication moves closer to enterprise expectations, the most common blind spot is treating login as a point feature rather than as part of the identity lifecycle. Redirect validation, factor persistence, and offboarding logic all need to be governed together or the assurance model fragments.

For practitioners

• Restrict redirect URIs to known callback endpoints Allow only explicitly approved callback URLs in the application and the identity dashboard. Validate organization membership and expected redirect targets before creating a session, especially in multi-tenant environments where a callback mismatch can create cross-tenant confusion.
• Persist MFA factors as governed identity records Store factor IDs, challenge IDs, and verification outcomes in a controlled identity model. Tie them to user status so enrolment, recovery, and revocation are handled when the account changes state or leaves the organisation.
• Prefer IdP-managed MFA where SSO is the primary pattern Use the identity provider's MFA capabilities when the app already depends on federated login. That keeps challenge policy and recovery logic in one place instead of splitting assurance controls between the app and the federation layer.
• Treat passwordless as an assurance decision, not a UX shortcut Assess email security, mailbox recovery, and one-time-code expiry before adopting passwordless at scale. If the delivery channel is weak, the login method simply relocates the attack surface instead of reducing it.

Key takeaways

• SSO, MFA, and passwordless can all improve enterprise readiness, but they also create different trust boundaries that must be governed separately.
• The main risk is not the login method itself, but the state that survives it, including callback handling, factor persistence, and recovery paths.
• Teams that want stronger authentication need to connect login design to lifecycle governance, offboarding, and auditability from the start.

Key terms

• Single Sign-On: Single Sign-On lets a user authenticate once with a trusted identity provider and then access connected applications without re-entering credentials. In practice, the application still has to validate the callback, tenant context, and session binding so the external assertion turns into the right local access decision.
• Multi-Factor Authentication: Multi-Factor Authentication requires more than one proof of identity before access is granted, such as a password plus a time-based code. The security value comes from combining factors with different failure modes, but it only works if factor enrolment, challenge, and recovery are governed through the full identity lifecycle.
• Passwordless Authentication: Passwordless authentication replaces memorised secrets with an alternative proof, often a one-time code, device signal, or linked identity flow. It reduces password reuse risk, but it shifts assurance to the delivery channel, recovery path, and surrounding account controls, which must be strong enough for the application’s risk level.

Deepen your knowledge

Authentication architecture for enterprise apps is covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning login design with identity governance in a .NET application, it is worth exploring.

This post draws on content published by WorkOS: How to add SSO, MFA, and Passwordless authentication to your .NET app. Read the original.