31

I am trying find documentation on "ALLOWED TOKEN AUDIENCES" in Azure, but there does not appear to be any. The value that I have placed in there was the resourceid that was returned with the token.

What does this mean? any link to documentation will be much appreciated.

PS. the learning link on the actual page mentions nothing about this, and the screenshots appear to be older and do not have this field.

thanks in advance

enter image description here

Thomas
  • 24,234
  • 6
  • 81
  • 125
noobie
  • 2,427
  • 5
  • 41
  • 66
  • 3
    I've been doing Azure AD authentication manually all this time, so I'm not quite sure about this one. Allowed audiences in Azure AD terms usually means "The values of the aud claim that we will consider valid for this API". So if someone calls your API that is protected by Azure AD, the aud claim in the token must match one of the defined ones here. You probably should not put the Azure AD Graph client id there :) – juunas Mar 07 '17 at 07:13
  • 1
    The ID looks like the resource ID for the Azure Graph API. Meaning that, as @juunas said, your application has some permissions to use that API. – RasmusW Mar 07 '17 at 07:32
  • 1
    Found this, and posted a comment asking what documentation she edited: https://github.com/MicrosoftDocs/azure-docs/issues/12377 – Tracy Nov 08 '18 at 22:40

5 Answers5

15

I've been stumbling around the documentation, too. Here's what I've gotten to work with an Angular Front-end app that consumes a back-end API app.

In the front-end app, the user clicks a link and authenticates with Azure Directory. The token is kept in session in the browser.

Next, the user wants to interact with the API app.
Here's how:

  • Go to the API App's App Service in Azure.
  • Navigate to Authentication/Authorization
  • Turn "ON" App Service Authentication
  • Under Authentication Providers Select "Azure Active Directory"
  • Choose "Advanced" button
  • In the Client ID field insert the "Application ID" from your API App's Azure Active Directory App Registration. You should have registered the API app in Azure Active Directory, already.
  • In the "Allowed Token Audiences" field insert the "Application ID" from your front-end app's Azure Active Directory App Registration. You should have registered the front-end app in Azure Active Directory, already.

Security is so important. It blows my mind how confusing the documentation is around this stuff. Owin/Katana looks like it's on the way out. Based on this configuration, you wont need any of it. The other sign that Owin is a goner is the massive breaking change related to Microsoft/System IdentityModel that seems impossible build, discern, fix, yada yada. I wish Microsoft would create an "endpoint" that would show what's out and what's in. and how to do this particular step. If you can get your apps to do this, it's real clean.

enter image description here

LargeDachshund
  • 916
  • 3
  • 12
  • 25
  • 5
    For some reason, I keep getting "You do not have permission to view this directory or page." when calling the API using access_token gotten earlier via the React based UI app. – Jussi Palo Apr 11 '18 at 09:01
  • 1
    To clarify, I believe what goes in the Allowed Token Audiences is the "App ID URI" value. You can get this by going to your front-end app's active directory registration page in the portal and then click Settings > Properties. – bwmartens Nov 07 '18 at 22:31
  • 1
    Or maybe it's the other app's App ID Uri. As mentioned ... documentation is impossible to find and I've lost a lot of hair trying to figure this stuff out. – bwmartens Nov 07 '18 at 22:37
8

Fast forward to 2020, and there is now some explanation on this parameter. (added in 2019)

https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad#-enable-azure-active-directory-in-your-app-service-app

Allowed Token Audiences

If this is a cloud or server app and you want to allow authentication tokens from a web app, add the Application ID URI of the web app here. The configured Client ID is always implicitly considered to be an allowed audience.

Grilse
  • 3,491
  • 2
  • 28
  • 35
  • I just came across this and I needed to add both the issuer and the Allowed Token Audience values. Then I got an auth token that was usable. – joe_coolish Oct 02 '21 at 02:56
5

In my experience, the value of this field (or one of the values) has to match what is in the "audience" field of the token that is being sent to your service (juunas said as much as a comment on the question above). bwmartens suggestion above to use the app id URI sounds like it would work but the current version of the AAD registration blade in the Azure portal does not list an "App ID URI" value nor does there appear to be a "Settings -> Properties" anymore (the site keeps changing).

In my case, just putting the application ID did not work. I have found that the two most straightforward ways to find the value needed here are:

  1. Go to the AAD registration for your service and look in the manifest at the "identifierUris" field. In my experience, the value here should match the value that you put in the Allowed Token Audiences list.
  2. Get a JWT that you are sending to your service and decode it (e.g. using http://jwt.calebb.net/) and look at the value of the "aud" field. Put that in the Allowed Token Audiences list.
Auth Infant
  • 1,760
  • 1
  • 16
  • 34
3

This is related to the JWT specifications.

"aud" (Audience) Claim:

The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case- sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.

The audience represents the application/resource you request access for.

When you're requesting an access token, you can specify:

  • a resource parameter: for example, I need an access_token to call the https://graph.microsoft.com/ API. The resource can also be the client_id of the application: 00000003-0000-0000-c000-000000000000.
    In this case, https://graph.microsoft.com/ is the identifier uri of the app registration and 00000003-0000-0000-c000-000000000000 is the client_id of the app registration. You can specifiy multiple identifier_uri when creating an app registration. Identifier uris and the client id are unique and can be used to request an access token for the MS Graph API.
  • a scope parameter: for example I need an access_token to call the https://graph.microsoft.com/ API but I only need user.read so the scope will be https://graph.microsoft.com/user.read.
    To acquire a token for all granted permissions, you can just specify {identifier_uri}/.default so in this case https://graph.microsoft.com/.default.

The identity provider will then issue a token for the requested application. The aud claim will be

  • The client_id if you specified resource=client_id as a parameter
  • The identifier_uri if you specified resource=identifier_uri or scope={identifier_uri}/... as a parameter.

Back to your question, when you're enabling Oauth2 on top of your app service, you need to specify some parameters:

  • client_id and client_secret: these are mostly used for the authorization code flow.
  • issuer: this claim identified who is issuing the token (= the identity provider). For AAD, it will be https://sts.windows.net/your-tenant-id or https://sts.windows.net/your-tenant-name. This ensures that the received token has been issued by the desired identity provider.
    By convention, the issuer claim also defines how to get the openid-configuration: {issuer}/.well-known/openid-configuration (see documentation). For simplicity, i would say the openid-configuration endpoint give information on how to validate the jwt token.
  • Allowed audiences: based on what we said, the allowed audiences can be the client_id or the identifier_uri(es) of the protected application.
Thomas
  • 24,234
  • 6
  • 81
  • 125
2

The error : JWT validation failed: IDX10214: Audience validation failed. Audiences:.... indicates that the allowedAudiences ARM configuration on your App Service needs to be corrected.

how to correct: The simplest way to do this is via https://resources.azure.com/. Drill down into the App Service resource > config > authsettings and correct the value(s) as below:

"allowedAudiences":[
"https://<site>.azurewebsites.net"
  ]

OR

you can navigate to portal and click on Advanced section of authentication and update the Allowed Token Audiences with the value of web app. With the current app service changes, it can be done automatically but good to check this configuration.

Currently most of people might be using OAuth 2.0 and for them the allowed token audience should get updated with the value of app registration id.

Please note that you can update Azure AD=> App registration => Expose an API => value of web app and that should work for you.

The value 00000002-0000-0000-c000-000000000000 represents Microsoft.Grpah resource but token should be issued for right resource to perform authorization.

Rohit Tatiya
  • 361
  • 2
  • 7