Access token has wrong audience

[aeons]

Hi,

I'm using acquiteTokenInteractively to request a token with scopes ["<clientId>/.default"] for an application with that clientId. I get a token back, but the aud claim is set to 29d9ed98-a469-4536-ade2-f981bc1d605e, which turns out to be the clientId for Microsoft Authentication Broker. The token also doesn't contain group claims which it is configured to do.

If I request the same token using the az cli (or one of our other apps) I get the expected audience and claims.

Am I doing something wrong or what is going on here?

[aeons]

Some more testing has revealed that this only happens on a physical device that is in shared device mode. Running the exact same code on a simulator works fine and returns the expected token.

[mipetriu]

Hi @aeons, could you reproduce the issue and send us an Authenticator log incident ID so I can take a closer look? If your device is in shared device mode, the option to submit logs should be right on the main screen in the Authenticator app.

[aeons]

Hi @mipetriu,

Apologies for the delay, I've been on vacation.

I have reproduced the issue and submitted the logs and a screenshot of our debug app with the claims from the token with incident ID DSQKNNFC.

Thanks

[mipetriu]

Hi @aeons, apologies for the long delay on my end as well, I had also taken some time off. Do you mind re-uploading logs? All logs are purged after a period of time. Thank you.

[aeons]

I have submitted a new log with id 4YTAHF5C.

[aeons]

@mipetriu, did you have a chance to look at the log?

[mipetriu]

@aeons, yes I've taken a look through the logs, and I have not been able to pick out anything incorrect yet. I've also tried to repro the behavior using a physical device in shared device mode, and so far I've only seen the correct clientID for my test app when acquiring a token interactively. Could you give some more detail about the testing steps you are taking? Maybe I'm missing something there.

I would also be interested to see a network trace to see what the server is returning in this situation. Would you be able to provide a Charles or fiddler trace, for example?

[aeons]

Hi @mipetriu

I tried creating a reproduction, but that turned out to work fine. A bit more digging revealed what the difference is.

For the simulator we are not going through the authenticator, and we were using the claims from the account in application.currentAccount(with: MSALParameters()), which had the correct audience and a custom claim we are using in our app.

When running on a physical device and going through the authenticator, we are able to request a token for the specific API we need, and the token we get back has all the expected claims. The difference is that the claims in the account are from a token for the authenticator itself it seems. I maybe get why that is since the authentication is going through the authenticator, but it was surprising that there is a difference in behaviour between authenticator and not-authenticator.

[mipetriu]

@aeons - Yes, the audience in the MSAL account is coming from the Authenticator app due to routing through the Authenticator app for increased SSO and security benefits.

It is recommended that if you'd like to perform any validation using the aud claim on your app side, it is better to use the claims in the ID token.

[aeons]

We just need a token to forward to a backend service, so I'm happy with our current solution. I guess I was just surprised by the difference in the MSAL account between using and not using an authenticator.

Thanks a lot for the digging :)