As a Cloud System Engineer I often work with Enterprise Applications and App Registrations.
But, what are these? How should I configure them & what are possible misconfigurations an engineer should be aware of?
In this article I will answer these questions.

What is an App Registration?

An App(lication) Registration defines an App.
Simple as that, it tells Entra ID, what the App wants and which API-access is allowed.
For example the App “MyTestApp” wants to read User profiles.
So the App Registration defines this, as you can see in the screenshot below:

The App Registration, especially their IDs are unique globally, even if they’re only available tenant-internally.
Entra ID uses shared components, so it’s necessary that every App Registration is uniqely identifiable and every App Registration can be uniqely spoken to.
In addition, the App Registration defines where the application is located, so you can also define Redirect and other URIs.

What is a Service Principal?

A Service Principal is a security principal and defines what permissions the application has in the tenant and it “represents” the Application in the directory.
So you will apply a conditional access policy to a service principal, not the app registration.
An other type of security principals are users, so as well as users, we can give a service principal permissions and resources.

In difference to the app registration, which defines what the application wants or needs, the service principal defines what the application is allowed to.

There are three types of service principals:

• Enterprise Applications
• Managed Identities
• Legacy

Legacy shouldn’t be used these days so we won’t focus on this type.

What is a Enterprise Application?

Enterprise Applications are like a child to service principals and referse to a Application externally or internally.
If you were working with Powershell or GraphAPI, you maybe used a cmdlet like Get-AzureADServicePrincipal, simply because Enterprise Applications are service principals.

Funfact: Microsoft Applications are using service principals as well, but just more integrated to Entra ID.

If you now want to access from another tenant (or maybe the same tenant), you need to have a service principal you can use.
You surely know the Consent Grant. That’s nothing more than the creation of a service principal and app registration in your tenant allowing and defining the required permissions.

How should I handle the registration process?

For example if you want to use the SaaS-application miro you can use Entra ID as a Identity Provider.
When signing up with your Entra ID Account on miro as a normal user, the default behaviour is, that it will prompt for the required permission, because User consent ist allowed(!) by default.
If a user approves this consent, the application can read or even write in your tenant.
Sounds strange, that your user can approve read or even write permissions for external apps without any Know-How? It is!
That’s why the default setting allow user consent is absolutely not recommended.
Either I recommend the setting verified publisher or even not allowed, if you’re a Company which needs 100% control about the registered applications or just don’t want to risk anything.

Summary

So check your or your customer tenants and define a setting which fits your needs.
In addition I recommend cleaning up your Enterprise Applications after blocking user consent, because with user consent enabled, there will be a looooot of trashy application your user approved, because it’s a *cool* App.