Could someone please tell me what the difference is between "enterprise application" and "app registration" in Azure.
Appreciate if you could give me an example & why some application cannot be registered under blade "Enterprise application" and vise versa.
An App Registration is a way of reserving your app and URL with Azure AD, allowing it to communicate with Azure AD, hooking up your reply urls, and enabling AAD services on it. When you have an application that you are developing and want to integrate with Azure, you need to register your application in App Registrations, where you will configure your reply URL, logout URL, and API access if needed. When you register your application, Azure AD assigns a unique Application ID to it and allows you to add certain capabilities such as credentials, permissions, and sign-ons. The default settings allow only users from the tenant under which your app is registered to sign into your application.
The Enterprise Applications blade might be confused with App Registrations because the Enterprise Application blade contains the list of your service principals. However, the term Enterprise App generally refers to applications published by other companies in the AAD gallery that can be used within your organization. For example, if you want to integrate Facebook and manage SSO within your organization, you can integrate it from the Enterprise Applications dropdown in the applications blade. Your own applications will also be represented in the Enterprise Applications blade as Service Principals, which are instantiations of your applications in the tenant.
App Registration: https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v1-add-azure-ad-app
Integrating an Enterprise application (G-Suite): https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/google-apps-tutorial
This is, I agree, potentially confusing to a new-to-AAD developer or administrator. Nitin's answer does a good job of summarizing this but I wanted to add an answer with documentation references.
At https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals it says:
The application object is the global representation of your
application for use across all tenants, and the service principal is
the local representation for use in a specific tenant.
Then, at https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-how-applications-are-added, it says:
You can manage application objects in the Azure portal through the
App Registrations experience.
Application objects describe the application
to Azure AD and can be considered the definition of the application,
allowing the service to know how to issue tokens to the application
based on its settings.
and
You can manage service principals in the Azure portal through the
Enterprise Applications experience. Service principals are what govern
an application connecting to Azure AD and can be considered the
instance of the application in your directory. For any given
application, it can have at most one application object (which is
registered in a "home" directory) and one or more service principal
objects representing instances of the application in every directory
in which it acts.
So, for third-party apps, you'll only have a service principal in Enterprise applications. For first-party apps that are internal, you'll have something in both places - one to define the app (App registrations) and one to allow the app to actually sign in to Azure AD (Enterprise applications). When you define the first-party app in the App registrations, you'll also automatically create an entry in Enterprise apps. If you look at the two entries, you'll see that the Application ID links the two together.
Shorter way to understand is...
App Registration are basically the apps local to the tenant/organization in which they have been registered to generate unique application id.
Enterprise apps blade shows global apps (belonging to other tenants) which can be configured and used within your tenant/organization.
The workflow is you create the App Registration (Application) in your tenant, which also creates the Enterprise Application (Service principal) in your tenant. Then when another tenant user wants to login to your app, they grant your app the permissions it requires and the Enterprise Application (Service Principal) is created in their tenant. This effectively mirrors your application in their tenant.
Additionally, within Application registration you can configure OpenId-Connect (OpenID/OAuth) based authentication. Within Enterprise Apps you can configure SAML based auth
Simple put:
Application Registration create an global application object which will allow the app to delegate to user identity for resource access, whereas the Enterprise application is the application identity(a service principle) in each AD tenant
Well, there're some good answers here but they are too verbose so I feel the simplest thing is show three pictures and one statement:
In the App Registration, we have "Application Objects":
To understand what you're seeing in the Enterprise Applications blade are "Service Principals":
And this is the relationship between the two in a multi-tenant example:
Adatum - The tenant used by the company that developed the HR app
Contoso - The tenant used by the Contoso organization, which is a consumer of the HR app
Fabrikam - The tenant used by the Fabrikam organization, which also consumes the HR app
And with that out of the way, we can understand this statement:
Similar to a class in object-oriented programming, the application
object has some static properties that are applied to all the created
service principals (or application instances).
The application object is the global representation of your
application for use across all tenants, and the service principal is
the local representation for use in a specific tenant. The application
object serves as the template from which common and default properties
are derived for use in creating corresponding service principal
objects.
Also said in a different way:
Application objects - Although there are exceptions, application
objects can be considered the definition of an application.
Service principals - Can be considered an instance of an application. Service
principals generally reference an application object, and one
application object can be referenced by multiple service principals
across directories.
Reference: https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
I understand the concept of AzureAD App Registrations and I'm using it in several projects. Now I need to generate a Web App that should be deployable as a component in any AAD. This Web App should use Azure APIs to discover components in the subscription it is deployed to which I don't know at develop time.
What is the preferred way to accomplish the app registration fully automated at deploy time? I need to register an app in AAD and then to store the informations (App Id, Tenant ID, ...) in my web.config somehow.
The problem is that you can't develop an app that has access to the Azure AD without it being registered first.
The Azure Portal and Powershell have access. Maybe you can use Powershell to script the permission grant in your scenario?
Otherwise, (I did this a while back for a solution) you can create a multi-tenant web app, that your customers' Azure AD tenant administrators can sign in to. With the tenant administrators granting access, the web app can then access their Azure AD graph API and create the required application definition for your application.
In my scenario the Azure AD client application ran on-premise. It required access to the Azure AD graph API and also needed certificate based authentication towards the Outlook 365 Exchange Web Service. So the web app could create the certificate, grant access to the required APIs, and let the user download the certificate, application ID etc. The on-prem app could then use the downloaded file as its configuration for accessing the Azure AD and other APIs.
I created a Azure Active Directory via the Azure portal. Then, I registered an app in it. I can configure it, add permissions and the like via the azure portal. But the same app I created, I don't see on https://apps.dev.microsoft.com/
Shouldn't I be able to see and configure the app I made in AD at that portal, too?
The apps that appear in the Application Registration Portal are the ones where you are explicitly marked as an owner of the application. This is in contrast to the apps that appear in the Azure Portal which are all the applications registered in your tenant, independent of whether or not your are an owner.
If you are a normal user, and you create an application in the Azure Portal, you should see your application appear in a section called "Azure AD only applications"
Here is the owner information for "Email Scraper" from the Azure Portal.
However, if you are a Tenant Administrator and you create an application, you will not be marked as an owner of the application. Implicitly, Tenant Administrators are owners of all objects in the directory, and to reduce the object quota generated by admins, these explicit links are not created.
Here is an example of an app I created where I am the Tenant Administrator:
Therefore, you probably do not see your application in the App Registration Portal because you are not marked as an Owner of the application, probably because you are an Administrator who created the app, or you did not create the app to begin with. You can remedy this by simply adding yourself to the owner list in the Azure Portal.
Let me know if this helps!
This isn't a specific problem question but a "cry for help".
My problem is this. Our organization is in the process of implementing Office365.
Until now there were tens of applications with their own authentication and authorization but in the process most of them will be rewritten to use within O365 environment.
We are facing the problem of creating one endpoint (ASP.NET WebAPI app) which will be used to authenticate a user with his credentials from Active Directory (or B2B AD on Azure because some apps are used outside) and tell if this user is allowed to use app that asked to log him.
I'm just wondering through documentations and sample code but can't decide what will be a good practice in this scenario. Should we just build each app and use Azure Active Directory provider to authenticate. Or is it possible to setup ONE api that will hold all apps Ids and its userIds - then it will check user credentials against AD and give app token/cookie...
My best bet is to try this: http://www.tugberkugurlu.com/archive/simple-oauth-server-implementing-a-simple-oauth-server-with-katana-oauth-authorization-server-components-part-1
But create Provider for AzureAD. But then its still question about this B2B AD part.
Please help by pointing to some up to date resources..
You should register each of your B2B application within your Azure Active Directory and configure them to use AAD as the Identity Provider.
Then you can administrate everything you want (e. g. which user has access to which application) within the Azure Active Directory blade from the Azure Portal.
You are getting this backwards. If you have apps integrated with Azure AD you don't have to create endpoint which will validate users right to use apps but you are assigning right to use an app in Azure AD. This is whole point.
I tried to grant delegated permissions to webApi using azure.portal.com.
Two web App/API application was register on azure AD. When i try to use 'Settings->RequiredPermissions->Add->Select an API' i not see my created application in list.
Same problem for old azure portal described on Granting native application access to web application
But new portal not fixed with previous solution.
Could anyone help, please ?
The Azure AD app registration blades in portal.azure.com are currently not creating a servicePrincipal in the tenant when you register your application. This means that the API you create will not show up in the list of apps to select from. More detail in this blog post