active-directory-aspnetcore-webapp-openidconnect-v2 for ASP.NET Core Identity

Why This ASP.NET Core Identity Tutorial Exists

This repository addresses a common split in an ASP.NET Core application: protecting the Web App itself and then acquiring access tokens for separate APIs. The tutorial starts with interactive user sign-in through the Microsoft identity platform, then extends the same Web App to call Microsoft Graph or APIs developed by the application owner. Its intended audience is ASP.NET Core developers implementing line-of-business applications, multi-tenant SaaS products, applications that also accept Microsoft personal accounts, and integrations intended for sovereign clouds.

The account model is an explicit design choice rather than a universal default. A line-of-business developer can focus on work or school accounts from one organization. A SaaS developer can accept accounts from any Microsoft Entra tenant, or combine organizational accounts with Microsoft consumer accounts. Separate chapters cover national and sovereign clouds and Azure Active Directory B2C for customer or small-business social identities. This structure is useful because changing `sign-in audience` is treated as a different application scenario rather than a minor configuration detail.

The project is a tutorial collection, not a packaged identity framework that can simply be installed and put into production without decisions. Repository directories include `1-WebApp-OIDC`, `2-WebApp-graph-user`, `3-WebApp-multi-APIs`, `4-WebApp-your-API`, `5-WebApp-AuthZ`, and `6-Deploy-to-Azure`. That layout maps the intended progression from authentication through API calls, application-owned APIs, authorization, and deployment. Teams should select the chapter that matches their application boundary instead of treating the repository as one monolithic sample.

Microsoft.Identity.Web and the Web App Authentication Flow

The first stage uses `Microsoft.Identity.Web` to secure an ASP.NET Core Web App with the Microsoft identity platform. Based on the chapter organization, the Web App authenticates the user first, after which later stages use the signed-in identity to authorize downstream requests. The repository supports browser-based sign-out both from the application and, through the tutorial path, from the browser session.

The downstream API path depends on OAuth access tokens rather than treating authentication cookies as API credentials. For Microsoft Graph, the tutorial directs developers through `2-WebApp-graph-user`. For other APIs, it moves into `3-WebApp-multi-APIs` and `4-WebApp-your-API`. The README also identifies conditional access, incremental consent, and claims challenges as topics in the broader API sequence. Those mechanisms matter because obtaining a valid user sign-in does not by itself settle whether a particular API call may proceed.

The sample also recognizes the browser architecture problem. One chapter uses the Hybrid SPA code flow to authenticate on the frontend and backend simultaneously. Another uses a Backend for Frontend proxy, authenticating on the backend and sharing authentication state with the frontend. The distinction is practical: these are different token and trust arrangements for JavaScript-heavy applications, not interchangeable labels. Repository layout indicates that both are options within the tutorial, and the README does not present one as universally preferable.

Choosing a Microsoft Entra and B2C Sign-In Audience

The `1-WebApp-OIDC` hierarchy makes audience selection the first architectural fork. `1-1-MyOrg` addresses users in one organization with work or school accounts. `1-2-AnyOrg` targets users from any Microsoft Entra tenant, which suits a SaaS application. `1-3-AnyOrgOrPersonal` broadens that model to work or school accounts and Microsoft personal accounts. `1-4-Sovereign` addresses applications intended for national and sovereign cloud environments, while `1-5-B2C` covers customer identities through Microsoft Azure Active Directory B2C.

This organization exposes a frequent operational cost. Choosing a broad audience changes the identity assumptions that registration, consent, security policy, and support procedures must address. The repository describes flexibility across these account categories, but it does not present every chapter as interchangeable. A developer copying the single-tenant chapter into a multi-tenant product would miss the point of the dedicated SaaS path. Conversely, opening a consumer-oriented application to personal accounts when it only needs organizational users adds an identity model the application may not be designed to support.

Azure Active Directory B2C appears in a separate tutorial path rather than as a generic feature switch. The top-level README does not provide detailed registration commands or configuration values for these cases, so exact tenant setup cannot be reconstructed from that document. The appropriate approach is to open the relevant chapter and its linked documentation, then confirm that its prerequisites match the intended customer or workforce model. The repository is explicit about the available scenarios, but it is not a compact deployment checklist.

Graph Token Caching and Multi-Tenant API Behavior

After sign-in, the Microsoft Graph chapters add two concerns that materially affect a Web App's architecture. The first is token caching. The README points to an incremental guide on cache serialization and names in-memory, Session token cache, SQL Server Cache, and Redis Cache as technology choices. These are materially different deployment models: an in-memory process cache, a browser-session-oriented cache, and two shared or persistent stores do not have the same scaling or failover properties. The README does not give enough detail here to declare a default or claim that one is always preferable.

The second concern is tenant scope. `2-3-Multi-Tenant` is dedicated to securing a multi-tenant SaaS application, so tenant handling is treated as application design work rather than merely adding Microsoft Graph permission strings. `2-4-Sovereign-Call-MSGraph` separately addresses Graph access in sovereign clouds. That separation is significant because the default cloud and sovereign cloud paths are not presented as one interchangeable endpoint configuration.

For Microsoft Graph, the tutorial's documented destination is `graph.microsoft.com`. The repository explains how an application moves from sign-in to obtaining downstream access, but the excerpt does not state the required `.NET` version, exact registration fields, package versions, or production cache settings. Those details must come from the selected chapter. The top-level README is a map of scenarios, not a sufficient source for production values.

Starting From the Repository Without Inventing Setup Steps

The README does not give a standalone installation command, application-registration procedure, or copy-and-paste first-run configuration. It directs readers to individual chapter README files, beginning with `1-WebApp-OIDC/README.md`, and states that some tutorial chapters remain in progress. Based on that documentation, the first real use starts by choosing the applicable audience chapter, such as `1-1-MyOrg`, `1-2-AnyOrg`, `1-3-AnyOrgOrPersonal`, `1-4-Sovereign`, or `1-5-B2C`, then following that chapter's own prerequisites.

There is no documented `dotnet restore`, `git clone`, package installation command, or environment variable block in the README, so none should be added here. The repository contains a `build.bat` entry and a `buildAllSlns.proj` project, but the README does not document the arguments or required setup for either file. Those entries indicate that the repository supports a Windows-oriented build path, yet they are not enough to claim a complete build procedure.

A first useful checkpoint is equally specific: follow one sign-in chapter until the Web App can authenticate the selected account type. Only then move to `2-WebApp-graph-user` for Microsoft Graph or the later API chapters. That preserves the tutorial's incremental structure and prevents downstream consent, cache, or authorization concepts from being mixed into the initial sign-in problem.

API Authorization, Azure Deployment, and Upgrade Cost

The later repository sections show that authentication is only one layer. `3-WebApp-multi-APIs` addresses Microsoft and Azure API calls, `4-WebApp-your-API` covers APIs developed by the application team, and `5-WebApp-AuthZ` introduces authorization. This separation is useful because protecting a Web App, registering an API, acquiring access for it, and deciding what the authenticated user may do are different concerns. The top-level README does not expose the detailed claims, policies, or package settings in those directories, so their exact behavior must be verified in the linked chapter files.

`6-Deploy-to-Azure` indicates that deployment is taught as a final stage. The tutorial overview says it includes deployment best practices, while the broader API chapter reportedly covers conditional access, incremental consent, and claims challenges. That scope means the upgrade cost is not just keeping C# source current. A team adopting it must also account for changes in Microsoft identity platform behavior, application registration policy, token caches, API consent, and cloud-specific endpoints.

The repository is not archived and its last push was on 2026-10-01, but the listed releases date from December 2020. A recent repository push therefore does not establish that every individual tutorial is synchronized with the latest identity platform documentation. Reviewers should inspect each chapter and compare its package references and setup assumptions with current Microsoft documentation.

The repository lists both `LICENSE` and `LICENSE.md`, and the repository metadata identifies the license as MIT. That supports reuse under the MIT terms, including use of the sample code subject to the license conditions. It does not remove operational obligations around identity configuration, registered applications, secrets or certificates, permissions, data handling, and API access. This section identifies those implications rather than offering legal advice.

Editorial conclusion

Developers building an ASP.NET Core Web App for Microsoft Entra-backed sign-in and downstream API calls should use this as a guided reference, while teams needing a complete current identity product deployment or non-Microsoft identity ecosystem should first assess its chapter structure and documented prerequisites. Verify the intended account audience, tutorial chapter, application registration requirements, and downstream API permissions before adapting the sample.

Frequently asked questions

Official sources

1. Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2 on GitHub
2. Issues
3. License: MIT
4. README
5. Releases