In this post I want to show, how you can create a claim aware ASP.NET Core Web App with C# in Visual Studio, in order to authenticate users against Azure AD.
In this post you will see how to authenticate against Azure AD using an ASP.NET web application (.NET Framework – Web Forms or MVC).
A few weeks ago, I also wrote a post with multiple parts about the Active Directory Federation Services (ADFS) and how to authenticate users in ASP.NET web applications against it beginning with Part 4.
Now let’s create an ASP.NET Core Web App to authenticate against your Azure AD.
You can also use the ASP.NET Core Web App (Model-View-Controller) template, there will be no differences regarding authentication against Azure AD.
With both templates, you just simply need to configure/adjust the appsettings.json file on part of your web app. The configuration in Azure is also the same for both types of web apps.
For the Authentication Type we need to select the Microsoft identity platform.
Finally click on Create.
Create and Register the Web App in Azure
Visual Studio will create the project and opens the appsettings.json file automatically.
Here we can see that we first need to configure the identity settings from our Azure AD tenant in order to authenticate against it successfully.
So this is different in contrast when creating an ASP.NET Web Application (.NET Framework – Web Forms or MVC) as shown in my following post.
For the ASP.NET Core Web App we have to configure by hand the tenant data in our web app and we also have to register by hand the web app in Azure AD – Enterprise applications.
Update 21.10.2023 !!! This has changed, now when creating a new ASP.NET Core Web App, a component named msidentity tool will be installed and makes it easy for us to configure this app to use the Microsoft Identity platform. (Azure AD and now called Microsoft Entra ID)
You can now create and register the app directly by using the Visual Studio wizard during creation of the web app.
Here you can click on Create new.
So first I have to collect the needed tenant information. Therefore I will browse to the Azure portal and Azure Active Directory overview site.
Here I need to take a note of the Tenant ID and Primary domain.
These information I will have to put in the appsettings.json file in my web app.
Next we need to register the web app in Azure AD and App registrations as follow.
First we have to take a note of the URI which we will find in the web app properties in the Debug menu.
Now we have all information to register the web app in Azure AD.
https://localhost:44378/
To register an app in Azure AD, normally you will do this in App registrations, but you can also use Enterprise applications which will use the wizard from App registrations, you will see this below.
In Azure AD -> Enterprise applications click on New application
Here we click on Create your own application
Also we need to provide a name for our app and have to select Register an application to integrate with Azure AD (App you’re developing)
Now click on Create
Using the Register an application to integrate with Azure AD (App you’re developing) option above, will bring up the same wizard as if you used App registrations first to register and adding your app as mentioned.
Here we will need to select who can use our application and the URI of our web app as noted previously.
To prevent you from making the same mistake as I did, the Redirect URI must also include the CallbackPath from your appsettings.json file.
“CallbackPath”: “/signin-oidc”
So the correct Redirect URI in my case will be the following: https://localhost:44378/signin-oidc
You will see further below the error I will run into without the Callback Path here entered.
Click on Register
Now we can see that our web app is listed and registered in App registrations from Azure AD .
In this quickstart, you register an app in the Azure portal so the Microsoft identity platform can provide authentication and authorization services for your application and its users.
The Microsoft identity platform performs identity and access management (IAM) only for registered applications. Whether it’s a client application like a web or mobile app, or it’s a web API that backs a client app, registering it establishes a trust relationship between your application and the identity provider, the Microsoft identity platform.
Registering your application establishes a trust relationship between your app and the Microsoft identity platform. The trust is unidirectional: your app trusts the Microsoft identity platform, and not the other way around.
Further the web app is listed as Service Principal Object in the Enterprise applications from your Azure AD.
Finally we have to take a note from the Application ID above and also needs to put it in our appsettings.json file from our web app for the ClientId.
Testing Azure AD Authentication
Let’s try if it works already.
Click on F5 to start debugging and run the application
Well, not really 🙁
AADSTS700054: response_type ‘id_token’ is not enabled for the application.
I can also check this failed login directly in Azure and my registered app in enterprise applications and there in the Activity section and Sign-ins.
The reason for is that our registered web app is not allowed to return an ID token.
Normally after we authenticated successfully against Azure AD (authorization server), our app will get an access token and ID token returned if enabled for, with the access token the app can access data on behalf of the user in Azure AD and with the ID token the app gets information about the user itself like its email address and name.
ID tokens are related to OpenID Connect, an identity layer on top of OAuth. As our app only needs to authenticate users from Azure AD and don’t need to access further data in Azure, we only need ID tokens from Azure AD (authorization server).
To enable our application to issue access tokens , we first have to configure it under Azure AD -> App registrations -> (select your web app) -> Authentication
Here inside the Implicit grant and hybrid flows section, enable ID tokens (used for implicit and hybrid flows)
More about the implicit grant flow you will find in the following Microsoft article.
Now it works and only for the first time, I have to consent to enable the application to access the data in my Azure AD tenant.
After the Accept (Consent in OAuth terminology), I was running into another error what I mentioned further above.
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application:
That’s the point regarding the correct redirect URI for my web app under App registration. Therefore I need to enter the CallbackPath from my web apps appsettings.json file and put it into the Redirect URIs in the Authentication section from the App registration.
Same site as previously to enable the access tokens.
Redirect URI: https://localhost:44378/signin-oidc
Now finally it works!
So configuring Azure AD authentication for ASP.NET Framework (Web forms or MVC) will take all the work about configuring the registration from my web app in Azure from me. In this case the Redirect URI and the ID tokens will be configured automatically from Visual Studio.
!! Note !! Update 21.10.2023 As mentioned further above this has now also changed by using a component named msidentity tool which will do all the registration work for us.
If you are interested to see how to analyze the authentication process, which is performed from Azure AD using the OAuth 2.0 and OpenID Connect protocol, you can read my following post about how to analyze AD FS SAML Claims with Fiddler. The process to capture the traffic and analyze it with Fiddler will be the same as for AD FS.
The second HTTP Request for login.microsoftonline.com will include in the response headers the JSON Web Token (JWT) issued from Azure AD(sts.windows.net) and OpenID Connect to authenticate using a HTTP Post against your web app.
You can also decode the ID Token above under the following link https://jwt.ms/
The site also lists clearly the claims after decoding the token.
These JSON Web Token (JWT) includes a set of default claims issued by default from Azure AD without the need to first configure them.
These claims contains a set of information about the user like the email address or the user principal name, in on-premises and the Active Directory they will be stored as Active Directory user attributes.
What set of information (claims) the JWT by default included, depends on the endpoint from where it was requested.
In case you need more claims as by default will be issued, you can add optional claims in the Azure portal and the App registration menu of your web app.
