Using client credentials flow in Azure for app registrations that live in different tenants, results in bearer tokens not containing any app roles.
I created 1 app registration named "fake-web-api" in Tenant A for a web api and that app registration contains an App Role named "fakeAppRole".
I created a admin consent link by using the following format https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}
I navigated to that link and signed in as an Admin of Tenant B and approved the consent.
This resulted in an enterprise application "fake-web-api" to appear in Tenant B's azure active directory.
I created 1 app registration named "fake-daemon-app" in Tenant B and added an API Permission to "fake-web-api"/"fakeAppRole".
I created a client secret for the "fake-daemon-app".
Now the code that I used to test this example is in here: https://github.com/Azure-Samples/active-directory-dotnetcore-daemon-v2/tree/master/2-Call-OwnApi
This example works perfectly fine for single tenant scenario, but when I tried to get it to work for muilti tenant scenario, I run into the problem that the bearer token that is returned to me does not contain any app roles and is therefor rejected by the "fake-web-api".
I expected the token that was returned to me to contain app roles, because it did contain app roles in the single tenant scenario.
In this case the issue turned out to be using Tenant A as the authority here:
.WithAuthority(new Uri("TENANT_A_DOMAIN_NAME"))
Since the app role was assigned in tenant B, we must use tenant B as the authority to see the role in the token.