You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a dotnet core app and a frontend application hosted in Azure. The frontend has its own "App registration" in azure ad and its client id is provided via our application settings which the backend is using in its Startup to configure authentication:
The respective configuration entry in the appsettings.json looks as follows:
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "...",
"ClientId": "<client it of the frontend app>"
}
Authorization is then enabled on controllers which required it with the [Authorize] attribute.
Now the situation is, that we have another frontend application which needs access to the same api. It also has its own "app registration"
in AzureAD and with it a different client id. I spent several hours trying to find resources and trying out things to configure the dotnet core app such that it accepts tokens with both client id's (which are present in the 'aud' field of the jwt token).
As a disclaimer, I am by no means an azure or security expert and do not really understand what exactly all terms refer to or how they relate to each other - alhough I would like to understand if what we are trying here is actually reasonable.
My intuition was that we have to somehow add "multiple client id's" to the backend - inspired by some posts and documentation I currently ended up with the following:
The config contains two configuration entries:
"AzureAdAuthentication": {
"AuthConfigForWebapp1": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "...",
"ClientId": "<client id of webapp 1>"
},
"AuthConfigForWebapp2": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "...", // the same as above
"ClientId": "<client id of webapp 2>"
}
}
This works... kind of. But there are several questions bugging me:
Now on every request the following error log is written:
fail: Microsoft.IdentityModel.LoggingExtensions.IdentityLoggerAdapter[0]
IDX10214: Audience validation failed. Audiences: '<client id of webapp 1>'. Did not match: validationParameters.ValidAudience: 'api://<client id of webapp 2>' or validationParameters.ValidAudiences: 'null'.
(or 1 / 0 reversed when requesting from the other webapp). Stepping through the library code, it seems to me that somehow "all possible schemes" are tried, whatever this means, but of course only one can work, because the jwt token contains only one client id?
Is there a way to fix this?
Defining two separate policies (for each scheme one) allows to block an endpoint for one webapp while opening it for the other by specifiying the AuthenticationScheme and Policy parameters of the Authorize attribute. With only one policy as above, this does not seem to work, the authentication scheme parameter does not seem to do anything. Why is this? What exactly is this doing?
Reading through several online resources I get the feeling that what we are trying to do is not really correct - almost every post fmo msdn or the wild explaining the configurations above refers to multi-tenant applications or multiple authentication types and other things which we dont have. We have just "two times the same" with a different client id. For example, is it correct, that we are defining a separate app registration for a webapp? Is that the idea?
Thank you and sorry for the lengthy post, I am new to the whole cloud subject and so far it seems like a giant blackbox for me.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
We have a dotnet core app and a frontend application hosted in Azure. The frontend has its own "App registration" in azure ad and its client id is provided via our application settings which the backend is using in its Startup to configure authentication:
The respective configuration entry in the appsettings.json looks as follows:
Authorization is then enabled on controllers which required it with the
[Authorize]
attribute.Now the situation is, that we have another frontend application which needs access to the same api. It also has its own "app registration"
in AzureAD and with it a different client id. I spent several hours trying to find resources and trying out things to configure the dotnet core app such that it accepts tokens with both client id's (which are present in the 'aud' field of the jwt token).
As a disclaimer, I am by no means an azure or security expert and do not really understand what exactly all terms refer to or how they relate to each other - alhough I would like to understand if what we are trying here is actually reasonable.
My intuition was that we have to somehow add "multiple client id's" to the backend - inspired by some posts and documentation I currently ended up with the following:
The config contains two configuration entries:
the configuration in Startup.cs looks as follows:
This works... kind of. But there are several questions bugging me:
(or 1 / 0 reversed when requesting from the other webapp). Stepping through the library code, it seems to me that somehow "all possible schemes" are tried, whatever this means, but of course only one can work, because the jwt token contains only one client id?
Is there a way to fix this?
Defining two separate policies (for each scheme one) allows to block an endpoint for one webapp while opening it for the other by specifiying the AuthenticationScheme and Policy parameters of the Authorize attribute. With only one policy as above, this does not seem to work, the authentication scheme parameter does not seem to do anything. Why is this? What exactly is this doing?
Reading through several online resources I get the feeling that what we are trying to do is not really correct - almost every post fmo msdn or the wild explaining the configurations above refers to multi-tenant applications or multiple authentication types and other things which we dont have. We have just "two times the same" with a different client id. For example, is it correct, that we are defining a separate app registration for a webapp? Is that the idea?
Thank you and sorry for the lengthy post, I am new to the whole cloud subject and so far it seems like a giant blackbox for me.
Beta Was this translation helpful? Give feedback.
All reactions