Category: App Services

All about application services for example, Azure App Service. Angular application, Microsoft .NET Core and EF

idTokenClaims vs accessTokenClaims

n the context of authentication, an “idtokenclaims” refers to the specific user identity information contained within an ID token, used primarily for verifying a user’s identity, while an “access token” grants authorization to access specific resources on a server, essentially acting as a key to access protected data based on the user’s permissions; meaning, an ID token tells you who the user is, while an access token tells you what the user is allowed to do.

Key differences: 

  • Purpose: An ID token is used for user authentication, displaying user information on the front-end like name and email, while an access token is used to authorize access to specific resources on a server. 
  • Claims: ID token claims usually include basic user information like name, email, and user ID, while access token claims specify the allowed scopes or permissions for a particular resource. 
  • Usage: A front-end application typically directly reads and displays information from an ID token, while an access token is sent with API requests to the server to verify authorization. 

Example:

  • ID token claim example: When you log in to a website, the ID token might contain your username and email address, which the website can display on your profile page. 
  • Access token claim example: If you want to access your private documents on a cloud storage service, the access token would specify your permission level (read only, read/write) to access those documents. 

Extending HttpClient With Delegating Handlers in ASP.NET Core

Delegating handlers are like ASP.NET Core middleware. Except they work with the HttpClient. The ASP.NET Core request pipeline allows you to introduce custom behavior with middleware. You can solve many cross-cutting concerns using middleware — logging, tracing, validation, authentication, authorization, etc.

But, an important aspect here is that middleware works with incoming HTTP requests to your API. Delegating handlers work with outgoing requests.

Read more here

https://www.milanjovanovic.tech/blog/extending-httpclient-with-delegating-handlers-in-aspnetcore

App Registration vs Enterprise Applications

All applications that get registered in AAD, in the tenant, two types of objects get created once the app registration is done.

  • Application Object
  • Service Principal Object

The Application Object is what you see under App Registrations in AAD. This object acts as the template where you can go ahead and configure various things like API Permissions, Client Secrets, Branding, App Roles, etc. All these customizations that you make to your app, get written to the app manifest file. The application object describes three aspects of an application: how the service can issue tokens in order to access the application, resources that the application might need to access, and the actions that the application can take.

The Service Principal Object is what you see under the Enterprise Registration blade in AAD. Every Application Object (created through the Azure Portal or using the Microsoft Graph APIs, or AzureAD PS Module) would create a corresponding Service Principal Object in the Enterprise Registration blade of AAD. A service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.

Similar to a class in object-oriented programming, the application object has some static properties that are applied to all the created service principals (or application instances).

You can read more on the following objects here: https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals

Reference

https://learn.microsoft.com/en-us/training/modules/implement-app-registration/2-plan-your-line-business-application-registration-strategy

How to prevent Visual Studio from compiling TypeScript

If you are building a Single Page Application / JavaScript Web application using Visual Studio, you’ve probably already run into the overlap between tooling that surrounds npm and the tooling within Visual Studio.

One of these tasks is preventing Visual Studio from being responsible for building TypeScript and allowing your tooling (i.e. Webpack, Gulp, Grunt) to be in charge instead. The idea here is that your tooling has been configured to lint, minify, build, concat, bundle, copy, whatever all of your project files exactly as you desire. At this point you don’t really need MSBuild involved in transpiling your JavaScript to TypeScript as it would be redundant and often times problematic. To prevent Visual Studio from doing any compilation of TypeScript preform the following steps:

Ensure a tsconfig file is added to the project and configured correctly

TypeScript and any build process you are using will work together based on the configuration in tsconfig.json. This file can be hand-rolled from scratch, or may have been generated for your project from a process like ng new and the Angular CLI. You can also generate a default tsconfig file (recommended approach as opposed to creating from scratch) using the following command:
tsc --init

This will generate a default configuration file for TypeScript compilation. Your web-client’s code build process will need to point to this file and using it as a driver for the TypeScript compilation behavior.

2. Modify the .csproj project file to prevent TypeScript from compiling

Within Visual Studio, right-click your project and select the option to edit the .csproj file. These options are in a XML format and the following needs to be added:
<PropertyGroup>
   <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
</PropertyGroup>
If you still want MSBuild to handle your TypeScript compilation there are several options that will change the behavior: 

Reference

https://www.typescriptlang.org/docs/handbook/compiler-options-in-msbuild.html