If you have developed anything related to Azure, you come across the terms Application Objects and Service Principals. I decided to write this post to explain these terms to serve as a reference for me and anyone who comes across it.

Application Object

You can consider an Application Object as a definition of your application presented to Azure AD. This definition contains information such Name, Logo, Redirect URIs, Secrets and other properties. But remember, not all these properties are currently exposed programmatically.

An Application Object can represent a Web API (application that you make available to client applications by exposing permissions/scopes and roles) or a client application (such as Web, Mobile or Desktop apps). An application object will only exist in its home directory, even if it’s a multi-tenant application supporting service principals in other directories.

You can register new Applications by going to Azure Active Directory service. Under Manage, select App registrations.


What should you enter for the redirect URI? For web applications, provide the base URL of your app. For example, https://localhost:31544 might be the URL for a web app running on your local machine. Users would use this URL to sign in to a web client application.

For public client applications, provide the URI used by Azure AD to return token responses. Enter a value specific to your application, such as myapp://auth.

Application’s Overview page.

Service Principals

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.

A Service Principal may have a reference that points back to an application object through its application ID property.  Remember that it is still possible to create service principals through different pathways, such as using Azure AD PowerShell, without first creating an application object. In this case, the service Principal will not have a reference back to any Application object.

As mentioned earlier, we can use PowerShell to create a Service Principal. Another way a Service Principal can be created is through the sign in process to access an application. During sign-in, users are asked to give permission to the application to access their profile and other permissions. The first person to give consent causes a service principal that represents the application to be added to the directory.

Service principals are what govern an application connecting to Azure AD. Service Principals can include records of local user and admin permissions granted to the application, local policies including Conditional Access policy, local user and group application-role assignments etc.

You can manage service principals in the Azure portal through the Enterprise Applications.

I hope you enjoyed the post.