What is the difference between using API permissions and using Authorized Client Applications

Question

I have been using Azure AD for over 4 years now and just today I saw that I could add "Authorized client applications" under Explore an API when I am setting up an application in Azure Entra ID (formerly Azure AD).

I have always been using API permissions when a client app needs to access APIs exposed by a different app. The way I would have been doing this is by having 2 apps registered in Entra, one of them exposing some scopes (and or App roles) and the other one having this scope under API permissions. I will almost always provide admin consent over this scope. I am putting some screenshots below to show how it looks like.

Setting scopes of an exposed API

The App using the scope as a permission

Then I noticed a few hours back that I can authorize client applications in the same screen as exposing the API scopes. But I have no idea what this does and how different this is from what I have been doing. What kind of use case should I use this feature instead of adding permissions in my client applications?

Answer 1

API permissions are used to grant access to specific scopes or permissions that are defined by the API. The user or administrator is requested to provide consent when a client application seeks access to the API, specifying the scopes or permissions that it requires.

• The client application can use the designated scopes or permissions to access the API when approval has been given.

For sample, I granted user_impersonation API permission that is defined by Azure Service Management API that allows access to the API as users:

Authorized client applications means that the client application is trusted by the API, when client calls the API they will not need to consent.

For sample, In Single tenant, the user will be able to directly login without providing any consent when the ServerApp API is called by the ClientApp if the ClientApp is added as Authorized client applications:

https://login.microsoftonline.com/TenantID/oauth2/v2.0/authorize? 
client_id=ClientID
&response_type=code  
&redirect_uri=https://jwt.ms
&response_mode=query  
&scope=api://ServerAppID/test.read
&state=12345

In multitenant scenarios, I created an ClientApp and added ServerApp API permissions like below:

Now when I tried to sign-in to the application using other tenant user, I got the error:

https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize? 
client_id=ClientID
&response_type=code  
&redirect_uri=https://jwt.ms
&response_mode=query  
&scope=api://ServerAppID/test.read
&state=12345

AADSTS650052 The app is trying to access a service xxx(ServerApp) that your organization xxx lacks a service principal for. Contact your IT Admin to review the configuration of your service subscriptions or consent to the application in order to create the required service principal.

In this scenario, adding the ClientApp as the Authorized client applications in the ServerApp is mandatory.

After adding , the user is now able to successfully login: