Skip to main content

Making sense of Azure AD Endpoint and Token Versioning

"error=“invalid_token”, error_description=“The signature is invalid”" is the error which stared me in the face. I was trying to use an Azure AD access token to authenticate with a .NET Core Web API protected by Azure AD. I inspected the token in JWT tool and immediately it became apparent that Issuing Authority name was wrong. "iss":"https://sts.windows.net/<tenantId>", even though the token was requested from an Azure AD v2 endpoint. So what gives!

To understand what is happening, let's understand the history of Azure AD. AAD has undergone life cycle changes where it has moved from a v1 to v2 and re-branded itself as Microsoft Identity platform. As part of that the issuing authoring has changed from sts.windows.net to login.microsoftonline.com. As there were already many applications relying on AAD when this change was made, Microsoft decided to support both the versions. Now this is where AAD tries to be extra clever which is not apparent at first glance.

When you register an application in AAD, there is a manifest generated for it. It contains a key accessTokenAcceptedVersion whose value is set to null. This means this app accepts token issued in v1 format which contains the issuing authority as sts.windows.net. If your app requests for an access token for this resource (by specifying it in the Scope), the token will be issued in a v1 format even though the you are requesting it from a v2 endpoint! To get the token in a v2 format, change the accessTokenAcceptedVersion to 2.

Hopefully Microsoft changes the default behavior to return token based on the endpoint version you are requesting it from and not the accepted token version of the resource you are requesting it for.

Comments

Popular posts from this blog

Pi Hole - Ad blocking (Turbocharged!)

The entire internet is now made up of ads. To easily navigate it and find the information you are looking for, most people use ad blocking software. It improves page loading times and also uses less data (sometimes by up to 10 times!)
Google Chrome is the de facto browser of choice for most people. Google's main business is advertising. So you can see how ad-blocking software collides with Google's business objectives. When Chrome was trying to be popular, it started allowing plugins like AdBlock Plus etc. Then slowly it started partnering with them for "Acceptable Ads Program" for a lot of money. Now after cementing its position as the most popular browser, Google is now coming down hard on ad blocking software. It is turning off a Chrome API (webRequest API) which most ad blocking plug-ins use to block ads.
Enter Pi Hole. This is an amazing use of Raspberry Pi which blocks ads before they enter your network. It keeps a blacklist of most popular ad serving domains …

Centralized Configuration for .NET Core using Azure Cosmos DB and Narad

We are living in a micro services world. All these services are generally hosted in Docker container which are ephemeral. Moreover these service need to start themselves up, talk to each other, etc. All this needs configuration and there are many commercially available configuration providers like Spring Cloud Config Server, Consul etc. These are excellent tools which provide a lot more functionality than just storing configuration data. However all these have a weakness - they have a single point of failure - their storage mechanism be it a file system, database etc. There are ways to work around those but if you want a really simple place to store configuration values and at the same time make it highly available, with guaranteed global availability and millisecond reads, what can be a better tool than Azure Cosmos DB!
So I set forth on this journey for ASP.NET Core projects to talk to Cosmos DB to retrieve their configuration data. For inspiration I looked at Steeltoe Configuratio…

Enabling IT in Healthcare by simulating Patient Data

In the current times of pandemics and disease outbreaks, it is of paramount importance that we leverage software to treat diseases. One important aspect of healthcare is Patient Management. IT systems have to be developed which can support management at an enormous scale. Any development of such good software system requires data which is as realistic as possible but not real. There has to be a fine balance between privacy and enabling developers to anticipate the myriad health scenarios that may occur. Towards this initiative, healthcare industry has been standardizing around the HL7 (Health Level 7) protocol. The HL7 protocol itself has undergone transformation from pipe-based formats (v2.x) to JSON/XML based (FHIR) modern formats. FHIR is the future of HL7 messages and is being increasingly adopted. However given the slow nature and reluctance by healthcare providers to change or upgrade their systems, a majority of hospitals still use the HL7 2.3 format.
FHIR is a modern format. …