Issuer URL is sts.windows.net instead of login.microsoftonline.com

[hpsjakob]

Hi,

I'm trying to implement a OAuth using this lib.
My problem is that the issuer of the token is "https://sts.windows.net" instead of "https://login.microsoftonline.com/.../v2".

According to this thread this is caused by a wrong token version. So I've tried setting "accessTokenAcceptedVersion": 2 and waited a few days. However, it did not change.

I'm using the lib in version 1.24.0. It would be great if someone could give me a hint!

[bgavrilMS]

Hi @hpsjakob - can you please clarify what you mean by "implement a OAuth"?

What type of application do you have? A console / desktop app, a web site or a web api? And what are you trying to do - do you need to sign-in users or do you need to call a protected downstream web api (e.g. Microsoft Graph, or your own API)?

https://sts.windows.net/ is equivalent to https://login.microsoftonline.com/ and a token validator needs to take that into account.

[hpsjakob]

Hi,
thank you for the quick reply.
I'm building a console Application.
In a nutshell my App looks like this:

app = PublicClientApplication( "XXX",  authority="https://login.microsoftonline.com/XXX")
response = app.acquire_token_interactive(["user.read"])
return response['access_token']

Then I use the token again an custom Spring Boot app that verifies the token using this mechanism.

There we validate that the JWT issuer matches https://login.microsoftonline.com/XXX/v2.0.

We're doing the same from a Single Page App (JS) and from there we get the JWT with https://login.microsoftonline.com issuer.

Do you have a hint / example for a correct Token validation in Spring Boot?

[bgavrilMS]

Unfortunately we do not yet have an AAD token validator for Java, only for .NET and for NodeJS.

Is there a way to pass in a list of allowed issuers in the Spring Boot token validation package? AAD maintains a list of names for each cloud that are valid issuers. See the aliases from https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fv2.0%2Fauthorize

CC @jmprieur and @jennyf19 for token validation in Java

[hpsjakob]

ok, I'll see if I can change this. But isen't it also an indicator for a Problem that the one tokens issuer ends with /v2.0 and the other does not. To me it looks like they're different versions.

[bgavrilMS]

The format of the token (v1 or v2) depends on the resource it is for https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#token-formats. Since you added "accessTokenAcceptedVersion": 2 on the web api, you'll be getting v2 access tokens consistently.

The hostname of the issuer is one of the 4 possible values, as per discovery call above. The .NET token validator makes the discovery call on its own and hides this complexity.

[hpsjakob]

hm ok.
So I'll add a handling for the different URLs.
However now I took a closer look on the Token and it contains the claim "ver": "1.0", so I guess there is still somethign else wrong with the version.

I double checked, I my Manifest it sais "accessTokenAcceptedVersion": 2,.

Is there something else I need to look out for?

[bgavrilMS]

Hmm, something is wrong then. Do you have a different app registration for the client (the python console app) and the web api (the Java Spring) ? The setting should go on the web api app registration.

[hpsjakob]

yes, it's the same App Registration. But two different Platform configurations. But this should not be a problem, right?
The accessTokenAcceptedVersion I added right in top of the Manifest file.

[bgavrilMS]

I don't think it should be a problem, but you can try creating a separate app and expose a web api on it and change accessTokenAcceptedVersion=2 and check.

In any case, the issuer alias problem is the same.

[hpsjakob]

Hi,
I compared my code again to the one in our SinglePage app and found that I was midding the scope api://XXX/access_as_user. Once I specified this scope I recieved a token with V2.
Strage...

Anyway I think we can close this.