Azure Active Directory (Azure AD) acts as a central identity service and manages all apps in a tenant. When it comes to app management, Administrators often are confused why there are two (or currently three) application management modules existing in the Azure portal. Well, see the explanation here.
An app can have many properties. The important part is, that Azure AD assigns an unique Application ID to an app and allows developers to add certain capabilities such as permissions, conditional access and more that is used by applications to access specific services.
Different app types?
The Azure portal shows various modules in the "Manage" category in Azure Active Directory module: "Enterprise applications" and "App registrations" (and the App registrations (Legacy) for provisioning an app with the old wizard – the new module is recommended).
Let´s start with the App registrations.
App registrations
The Azure portal is the central place to register your organization´s applications. Microsoft wanted to avoid the confusion from the past where multiple portals were available to register an app, now it´s all in here.
When creating a new app, the administrator decides who can access that app. Mostly, the app is to be used within the own tenant. Other options are Multi Tenant and MSA support that can be selected as well. Of course, these settings can be changed later.
To find our more about app registration, check out the following resources:
- Quickstart: Register an application with the Microsoft identity platform
- How and why applications are added to Azure AD
- Azure Active Directory Identity Blog.
So, the "App registration" basically shows all apps in your tenant that have been registered.
Enterprise applications
In the Enterprise applications module, Global Admins by default see "external" apps that are published by other companies in the Azure AD gallery that can be used within your organization. This is because the dropdown filter "Application Type" is set to "Enterprise Applications".
The "Enterprise Applications" blade contains the list of existing Service Principals in your tenant. Your own tenant applications will also be represented in the Enterprise Applications blade as Service Principals. Switch the Application Type filter to "All Applications" as here.
You should now see all "App registrations" in the "Enterprise applications" and have access to all the enterprise features.
More Enterprise App details
In the Enterprise Apps, you can control in Azure AD who has access to a specific app. Admins can define the app permissions for "Owners", "Users ang groups" and decide policies for "Conditional Access". So these are are great features for management.
Additionally, we see the users that have logged-in to an specific app, e.g. the Enterprise App "Graph Explorer" here has been access by Adele and by the Administrator.
We can also see when the app was accessed by what user in the "Sign-ins":
…and there are many more app features available. For more details, follow the links above.
How apps show up in the Enterprise Applications
Once a user or an administrator in your tenant consents to an external app, the app shows up in your tenant´s "Enterprise applications". So, if a user opens e.g. the publicly available "Graph Explorer",signs-in and consents to it, this app is added to the tenant´s apps. The tenant admins can then configure that app in the same way as the other apps if required.
Background of Multi-Tenant Apps
Apps from third parties are classically multi-tenant Apps. Imagine, you are the app maker. This means, you only need to do the application registration once – as Multi Tenant App as shown above - in your own tenant which creates the Enterprise Application (Service Principal). When another tenant user wants to login to your app (identified by the world-wide unique App ID), they grant your app the permissions it requires – the "consent". If agreed, the Enterprise Application (Service Principal) is created in their tenant and this app effectively mirrors your application in their tenant. So one app can be used in multiple tenants.
Change of permissions
If app permissions are changed, the users in all tenants have to consent to the new app permissions. This happens automatically, controlled by the Azure AD since it knows the consent of each app and user. A user has to confirm the permissions to be able to use the (existing) app (with the new permissions).
When to use what module
So, you need to provision a new app and the basic app properties in the "App registrations". Use the "Enterprise applications" - and switch the dropdown filter to "App registrations" - to manage more features as "Conditional Access" or permissions, logs, and so on.
Happy app-management!