Using Azure AD B2C for external user authentication in .NET apps

Consumer-facing applications often need a secure sign-in experience without forcing customers, partners, or community members to create a corporate Microsoft account. Azure Active Directory B2C, commonly called Azure AD B2C, provides a managed identity platform for this scenario. It supports local accounts, social identity providers, multifactor authentication, password recovery, and standards-based integration with .NET applications.

For Australian software teams, the service can simplify authentication for users spread from Sydney and Melbourne to regional Queensland and Western Australia. It also gives development teams a consistent way to handle identity while they concentrate on application features, privacy obligations, and a smooth experience across mobile and web channels.

Understanding the external identity model

Azure AD B2C separates customer identities from workforce identities used in Microsoft 365 or an organisation’s internal Azure environment. A customer can register with an email address and password, or use an identity provider such as Google, Facebook, Apple, or another OpenID Connect service. The application receives tokens that describe the authenticated user without managing the user’s password directly.

The service is built around OpenID Connect and OAuth 2.0. OpenID Connect handles authentication and returns an ID token containing claims about the user. OAuth 2.0 provides access tokens for calling protected APIs. This distinction matters in a .NET solution: the web front end may validate an ID token, while an ASP.NET Core API should validate an access token issued for that API.

Azure AD B2C has traditionally used user flows and custom policies. User flows are preconfigured journeys for sign-up, sign-in, profile editing, and password reset. Custom policies provide finer control over claims, identity providers, conditional steps, and business rules, although they require more XML configuration and testing. Microsoft has also introduced Microsoft Entra External ID as the broader identity product direction, so teams starting a new system should check current Microsoft naming and migration guidance.

A B2C tenant should be treated as a dedicated identity boundary. It is usually separate from the tenant that hosts a company’s internal users and Azure resources. Applications, redirect URIs, user flows, API scopes, certificates, and secrets must be configured in the correct directory, or authentication errors can look confusingly similar to ordinary .NET configuration mistakes.

Configuring a .NET application

A typical ASP.NET Core application uses the Microsoft.Identity.Web package to connect OpenID Connect authentication to Azure AD B2C. Configuration is commonly stored in appsettings.json, environment variables, or a managed configuration service. A representative configuration includes the tenant domain, client ID, policy name, instance URL, and callback path.

{
  "AzureAdB2C": {
    "Instance": "https://contoso.b2clogin.com",
    "ClientId": "application-client-id",
    "Domain": "contoso.onmicrosoft.com",
    "SignUpSignInPolicyId": "B2C_1_signupsignin"
  }
}

The exact settings depend on the Microsoft.Identity.Web version and application type, so the package documentation should take precedence over copied snippets. In Program.cs, the web application typically registers authentication with an OpenID Connect scheme and enables token acquisition when it must call a downstream API. The middleware then challenges unauthenticated users and processes the callback from the B2C policy.

Redirect URI precision is essential. A local address such as https://localhost:5001/signin-oidc is different from a test hostname or a production address. HTTPS should be used outside local development, and every permitted callback must be explicitly registered. Wildcard redirect URIs are dangerous because they can enable token delivery to an unintended location.

For an ASP.NET Core Web API, use bearer authentication rather than interactive cookie sign-in. The API should validate the issuer, audience, signature, and required scopes. A controller can then use [Authorize] and, where appropriate, scope or policy checks to distinguish a signed-in user from a user authorised to perform a specific operation.

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAdB2C"));

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Orders.Read", policy =>
        policy.RequireClaim("http://schemas.microsoft.com/identity/claims/scope",
                            "Orders.Read"));
});

Token validation must happen on the server. A client-side application can hide buttons based on a claim, but that is only a user interface decision. The API remains responsible for enforcing permissions, ownership rules, tenancy boundaries, and business constraints.

Designing registration and sign-in journeys

A user flow should reflect the way customers actually use the product. A combined sign-up and sign-in journey is suitable for many applications, while separate profile editing and password reset journeys provide clearer control over account maintenance. The flow can collect attributes such as display name, country, phone number, or a customer reference, but every requested field should have a clear purpose.

Email verification is an important control for local accounts. It reduces fake registrations and helps prevent a customer from accidentally creating an account against another person’s address. A production design should also consider account enumeration: error messages should avoid revealing whether a particular email address already exists.

Claims should be kept small and stable. A subject identifier is generally safer for linking the B2C identity to an internal record than an email address, because users can change email addresses. Applications should store the immutable identifier and maintain their own customer profile, roles, subscription status, and audit information in an application database.

Social sign-in can reduce friction, particularly for consumer services used on mobile devices. It introduces another dependency, however, including provider-specific claim formats, consent screens, account linking rules, and outages. A user who first signs in with Apple and later chooses an email password may accidentally create two accounts unless the application has an explicit, secure account-linking process.

Australian services should also plan for accessibility and practical usage conditions. Customers may sign in during an arvo commute with a phone, on an unreliable regional connection, or through an older browser supplied by a workplace. Clear validation, responsive pages, low-bandwidth assets, and an accessible recovery journey have a direct effect on account completion rates.

Protecting data and meeting operational needs

Authentication configuration is part of the security boundary, not a one-off setup task. Client secrets should be stored in Azure Key Vault or an equivalent secret manager, with restricted access and rotation procedures. Certificates are preferable for some confidential client scenarios, and production credentials should never be committed to source control or embedded in a JavaScript bundle.

Multifactor authentication can be introduced through B2C user flows, custom policies, or a selected identity provider. The right method depends on the application’s risk profile. A banking-adjacent service may require stronger controls than a public events portal, while a marketplace may need step-up verification for payment or account recovery actions.

Privacy planning is particularly relevant in Australia. The Privacy Act 1988 and Australian Privacy Principles can affect notice, collection, use, disclosure, access, and retention of personal information. The Office of the Australian Information Commissioner expects organisations to handle personal data transparently, so a privacy notice should explain why identity attributes are collected and which providers or processors are involved.

Data location needs careful review rather than an assumption that an Australian Azure region automatically stores every identity record in Australia. Azure AD B2C service availability, tenant configuration, diagnostic data, and Microsoft service terms can involve different locations. An Australian organisation with customers in Sydney, Brisbane, or Perth should document its data-flow assessment and obtain legal or compliance advice where regulated information is involved.

Operational resilience also requires a support path. Teams should monitor failed sign-ins, policy errors, unusual registration bursts, token validation failures, and dependency outages without logging passwords or raw tokens. Correlation IDs and carefully selected claims make incidents easier to investigate. During a major release, a staged rollout and a tested rollback path are safer than changing identity policies directly during peak customer activity.

Comparing implementation choices

The best integration approach depends on the type of .NET application, the trust boundary, and how much control the team needs over the user journey. A server-rendered ASP.NET Core site generally benefits from cookie-based sessions after an OpenID Connect sign-in. A single-page application should use an appropriate browser authentication flow and avoid storing long-lived secrets in the browser. A separate API needs its own app registration and exposed scopes.

Custom policies are valuable when a standard user flow cannot represent the required process, such as progressive profiling, account linking, or a multi-step identity verification journey. They also increase the amount of configuration under test. Teams should begin with the simplest supported flow and move to custom policies when a documented business requirement justifies the added maintenance.

A useful delivery sequence is to register the application, create a basic sign-up and sign-in flow, connect a development .NET client, and protect a small test endpoint. The team can then add profile attributes, social providers, multifactor authentication, and custom authorisation policies incrementally. Automated tests should cover successful sign-in, cancelled sign-in, expired sessions, invalid scopes, password reset, changed email claims, and disabled accounts.

For an Australian product, launch readiness should include support scripts written in plain local English, monitoring aligned to Australian business hours, and a documented response for identity-provider outages. Teams serving customers across multiple states should test daylight-saving differences, especially when support staff operate from Sydney, Melbourne, or Hobart while users access the service from Queensland or Western Australia. With sound token validation, careful privacy governance, and a user journey designed for real conditions, Azure AD B2C can provide a dependable external authentication layer for modern .NET applications.