App Registration vs. Enterprise Applications
Updated: Dec 17, 2021
Think of an App Registration as a way of reserving your app + URL inside of Azure Active Directory (Azure AD or AAD). An App Registration provides a way for your app to communicate with AAD: you'll be able to use reply URLs and enable AAD services on the app. Super big bonus!
So whenever you have an app you're developing and want to integrate with Azure, you need to register your application in App Registrations. You'll configure the reply URL, logout URL, and API access if needed. When an application is registered, Azure AD assigns the app a unique Application ID (which is a GUID). This allows any developer to add specific capabilities like credentials, permissions, and sign-ons.
The Enterprise Applications section can cause some confusion with App Registrations because Enterprise Application contains the list of your service principals. Keep in mind, the term Enterprise App usually refers to applications published by other software vendors in the AAD gallery. Think of this like Salesforce, G-Suite, Facebook, etc. Additionally, your own applications will also be represented in the Enterprise Applications section as Service Principals, which are symbolic of the applications in your AAD tenant. A Service Principal inherits certain properties from that application object. A Service Principal is created in each tenant where the application is used and references a globally unique app ID. The Service Principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access.
I thought I'd leave you with a few links to learn how this is set up:
Integrating an Enterprise application
And with that, I hope this post has helped you make sense of certain terminology within the land of Azure Active Directory!