Comparing a .NET Core application for the Identity Platform and Identity.Web
Note: Both these approaches rely on OpenID Connect. They do not cover SAML or WS-Federation.
The Microsoft Identity Platform “is an authentication service, open-source libraries, and application management tools”.
It is not a product and you can’t download it. It is essentially a collection of client-side libraries based on MSAL (the Microsoft Authentication Library) libraries. These cover a number of use cases, operating systems and languages.
You start off with create an “App Registration” in Azure AD.
You first decide who can login:
Then you use the quickstarts.
When you view the quickstart guides, you see:
And e.g. selecting “Web application”:
We pick the “ASP.NET Core” entry and you can then download a sample from Github, pre-configured for this tenant and clientID.
The libraries cover the “converged approach” that allows you to authenticate against Azure AD with an Azure work or school account, a Microsoft Live account or social accounts (e.g. Twitter) and also Azure AD B2C.
There is also a MSAL library that allows you to authenticate against ADFS on Server 2019.
Note: This wizard is not yet available in Azure AD B2C.
There are flows for the different scenarios:
Microsoft.Identity.Web “ is a library which contains a set of reusable classes used in conjunction with ASP.NET Core for integrating with the Microsoft identity platform (formerly Azure AD v2.0 endpoint) and AAD B2C.
This library is for specific usage with:
- Web applications, which sign in users and, optionally, call web APIs
- Protected web APIs, which optionally call protected downstream web APIs”
“It provides the glue between ASP.NET Core middle-ware and MSAL to bring a clearer, more robust developer experience, which also leverages the power of the Microsoft identity platform (formerly Azure AD v2.0 endpoint), and leverages OpenId Connect middleware, which means developers can develop applications which allow several identity providers, including integration with B2C.
Microsoft Identity Web also leverages the Microsoft Authentication Library (MSAL), which will fetch the tokens and provides token cache extensibility.
Today, without Microsoft Identity Web, when doing
dotnet new --auth
and creating a Web App from an ASP.NET core template, the application is targeting the Azure AD v1.0 endpoint”.
The “dotnet new” commands for this using the v2.0 endpoint are:
It is available as a NuGet package i.e. Microsoft.Identity.Web for .NET Core 3.1 and .NET 5.0 (preview).
Web apps can also use the Microsoft.Identity.Web.UI NuGet package
The approach follows an “incremental flow”:
i.e. you start off with a sample that authenticates to Azure AD as a web application using OIDC and then add code to call one API in Microsoft Graph and then call many API etc.
Once you have made that choice you then decide who can login in e.g. just users in my Azure AD tenant, any tenant etc.
There is a “subway map” to guide you:
“Clicking on a metro/railway station will get you directly to the README.md for the corresponding part of the tutorial (some are still in progress)
Clicking on some of the connectors between stations will get you to an incremental README.md showing how to get from one part of the tutorial to the next (that’s for instance the case for the Sign-in … stations)”
Once you have downloaded the sample, you have to manually configure the clientID etc. in the appsettings.json file.
You can also control the token storage.
The choices are:
- In-memory
- Session
- Distributed
You can customise some options e.g. OpenIdConnectOptions or JwtBearerOptions by using the Configure and PostConfigure methods in Startup.cs.
There is also a wiki.
So what is the difference from a code perspective?
Using the web application sample from both, we see:
The Identity platform sample is on the left.
So there is very little difference in the sample layout (as you would expect).
The appsettings.json files are similar:
Looking at Startup.cs:
We see that the Identity.Web sample uses Microsoft.Identity.Web and Microsoft.Identity.Web.UI.
You can see that the Identity Platform calls:
services.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => Configuration.Bind(“AzureAd”, options));
whereas Identity.Web wraps this in a :
services.AddSignIn(Configuration);
Running the Identity Platform sample shows:
and once you have authenticated:
The Identity.Web sample after authentication shows:
Note the user in the top right corner.
If you want to simply “Sign-in users in five minutes” use the platform, If you want to dig a bit deeper and customise use Identity.Web. There’s no reason you can’t mix and match between them.
All good.
