.net core - Azure AD OAuth generates token for audience without permission

Question

Despite reading multiple articles and tutorials at Microsoft.com, I am having an issue to understand how to define permissions between APIs using app registrations/OAuth2 in Azure AD. To exemplify, I have set up 2 simple app registrations in Azure AD, one for a back end API (lets say client ID A) and another for a front end or another API (client ID B). Then, I set up a basic .NET Core API with default (template) authentication (Options = tenant, client ID, etc) and the default weather forecast endpoint.

        services.AddAuthentication(AzureADDefaults.BearerAuthenticationScheme)
            .AddAzureADBearer(options => Configuration.Bind("AzureAd", options));
        services.AddControllers();

Right now, I am able to get a token from https://login.microsoftonline.com/<tenant>/oauth2/token with Client ID = B and resource = Client ID A, and when I send this token(with 'aud = A') to the API it accepts it.

Why is the token generated successfully, even though I have not set up any relationship between App Registrations A & B? The API Permissions tab in Azure AD is empty in both registrations - I thought AAD would reject the request stating that App B does not have access to App A. Or am I entirely responsible to validate audience claims via code on my app?

question from:https://stackoverflow.com/questions/65843851/azure-ad-oauth-generates-token-for-audience-without-permission

Answer 1

It is possible in Azure AD to acquire an access token through client credentials flow to an application that the client app has no permissions on. This may be to enable some scenarios where the target API handles the whole authorization, but I am not sure.

I wrote an article some time ago on the need to check permissions always: https://joonasw.net/view/always-check-token-permissions-in-aad-protected-api. I also wrote a follow-up after Microsoft addressed the cross-tenant ability to get access tokens: https://joonasw.net/view/cross-tenant-token-attacks-now-harder-in-azure-ad.

Because a client can get a valid access token without permission assignments, authorization is crucial on your API side. At our company we have a default authorization policy that checks every request that it contains either a valid delegated permission/scope or a valid application permission/app role. That gives us a baseline that already protects the API from tokens like that. It is usually not the only authorization applied. In case delegated permissions are supported, you need to check that the user also has access to the thing they are trying to do. Delegated/app permissions after all only say what the client app can do.