In my post about getting the Azure AD JWT via Postman, we kind of skipped over the part on what the resource is when requesting a token. Basically, its the Application Id URI of the app you will be calling, not the app you are login in as. Let's talk through a scenario, using the https://github.com/Azure-Samples/active-directory-dotnet-daemon sample from my post on Service to Service auth.
You would create two applications in Azure AD, and they don't even need to be in the same AD (we will cover that at a later date). The service that is going to consume the API (TodoListDaemon) is the one that would be using the method I described to get a bearer token, and it would have its own Application as we would use its App ID for the Client Id. Then the service hosting the API (TodoListService) would also have its own Application, but we don't need to generate an Application Key, as we are not logging on as this application. But in TodoListService we would put it's Application ID URI in as the "Audience" when configuring our authentication options.
Then when TodoListDaemon requests a token, it will put the Application ID URI for TodoListService as the resource. Azure AD will validate the URI is correct, and then add it as a claim in the JWT. When TodoListService checks the JWT, it can see that Azure granted the claim for this application and no others, and it can then trust all the other claims, like "act on behalf of", or any other role you setup in when you created the TodoListService application. Yet another topic for another day.
Because this field goes by so many names, here is a cheat sheet for some of the places you use the resource:
- Resource: this is used when making requests to the token endpoint.
- Audience: this is used when validating the JWT per request
- identifierURIs: this is in the Azure Active Directory application manifest
- App Id URI: this is what the documentation for the application manifest calls this value.