Protecting angular and ASP.NET core applications – An Overview.

In this and upcoming blog posts, I’ll be talking about integrating Azure Active Directory (AAD) and leveraging open source libraries to protect a system consisting of an angular application and ASP.NET core web apis.

In this post, I just want to give a high level overview of the setup and the technologies involved in securing such as system. As such, I likely gloss over some of the points. In subsequent posts, I’ll cover the specific parts in more details.

From angular to web api

The system consists of an angular application and two web apis, which I’ll call web api#1 and web api#2 respectively, for lack of other names. Both the api#1 and angular application are served by the same host. Web api#1 directly supports the angular application. Web api#1 and angular application are developed together in a same solution using the angular project template with ASP.NET core. The other api, web api#2 is for interacting with the backend database. The real system actually consists of a third API that is specifically for working with PDFs, but we don’t need to worry about it.

Registering the applications on AAD

The security aspect of the applications leverage Azure Active Directory. Each of the applications must be registered under the tenant. For instructions on registering applications under AAD, checkout the documentation.

Part of the registration for the angular app specifies the redirect and logout urls, as well as configures the necessary permissions to access web api#1

The registration for web api#1 defines the scopes and grants the angular application permission to access the api. In turn, the registration for web api#2 defines the scopes and grants web api#21 permission to access the api. For details on exposing an api and granting permissions, checkout the documentation.

Protecting angular

A user first arrives at the angular application, which uses the Microsoft Authentication Library (MSAL) for Angular to handle calling the authorization endpoint, obtaining the tokens and protecting the routes. For instance, the MsalServiceclass exposes methods to present the user the sign in page from Microsoft, either via a redirect or popup as well as obtain and manage the tokens. The MsalGuard protects an angular route by making sure the user has authenticated before allowing the user to access the route. The MsalInterceptor intercepts a http request to check and add the token to the Authorization header if necessary. As of this writing, the library is still in preview. It is not too hard to setup and get running. However, you may experienced difficulties to get it to work exactly the way you want without having to do much work around. For instance, I have faced the issue where the angular app refreshes itself after the initial sign in. For more details, checkout this issue on github.

The login flow uses OpenID Connect and Azure Active Directory. On login, the angular application calls the authorization endpoint and presents the user with the sign in page from Microsoft, either via a redirect or popup. At the end of the flow, the angular app has access to an id token representing the identity of the user. The id token, however, does not represent authorization to access protected resources under api#1. When making a request to a protected endpoint under api#1 the angular app makes another call to the authorization server to obtain an access token if necessary. For instance, the angular application needs to obtain an access token if in the first call to login, the scopes do not contain the appropriate value for obtaining an access token, or if the existing access token has become invalid. Once the angular application has obtained a valid access token, it includes the token in the Authorization header when making a request to a protected endpoint under api#1. For the specific details of how the flow works, checkout the documentation.

Protecting ASP.NET core web apis

The controllers under both web api#1 and web api#2 are protected using the Authorize attribute. When a request hits api#1, ASP.NET core first checks whether the header contains the token, and if so, it extracts and passes the token to the JwtBearer middleware. This part of the setup to require authorization and validate an access token are not that complicated and is the same for both web apis. For the most parts, you define what you want to validate via the TokenValidationParameters and let the libraries handle the validations for you. The JwtBearer middleware calls the validators under the Microsoft Identity Model Extension for .NET to validate the token, according to the validation parameters. For details of the setup, checkout the documentation.

Besides validating an access token, web api#1 needs to obtain its own access token from the authorization server to access web api#2. The web api#1 needs to communicate with web api#2 on behalf of the user. For instance, it proxies some of the requests from the angular application to web api#2 to get the data for the angular application. The communication between web api#1 and web api#2 follows the OAuth2 On-Behalf-Of flow (OBO). To access web api#2, web api#1 makes a request to the authorization endpoint to obtain its own access token for assessing web api#2. The request must includes the access token it receives from the angular application, which represents the user’s assertions. For more details of how the OBO works, checkout the documentation. In the codes, I am currently using the classes under the Microsoft.Identity.Client.Extensions.Web package. As of this writing, this package is not available yet as a Nuget package. I have had to literally copy the classes into my project to use. I suppose the Microsoft team would release the codes as a Nuget package soon for consumption. For now, you can checkout the package via the github repo.

You may wonder why don’t we just allow the angular application to communicate directly to web api#2, instead of having to go through web api#1. In this system, the angular application is accessible by the public; however, web api #2 is a private API, and we don’t want it accessible from just any host. By allowing the angular application to communicate only with web api#1, we can restrict access to web api#2 to specific hosts, and thus strengthen security. Furthermore, we don’t need to enable CORS. Ofcourse, the drawback with this setup is performance.

That’s it for now

Hopefully, this post has given you some ideas on how to protect a system of an angular application and ASP.NET core web apis. Such system is common nowadays, especially if your organization is a .NET shop. I’ll try to go in more details in subsequent posts. For now, let’s me know in the comments if you have questions.

Resources:

Quickstart: Configure an application to expose web APIs

Quickstart: Register an application with the Microsoft identity platform

Use the Angular project template with ASP.NET Core

Microsoft Authentication Library for Angular Preview

A look behind the jwt bearer authentication middleware in ASP.NET core

Protected web API – code configuration

Authorize access to web applications using OpenID Connect and Azure Active Directory

Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow