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.