What are App Registrations in Azure (Microsoft Entra ID)

Why do we need them

Some one asked me: “what does it mean when we create an app registration in Azure.”

Well, Microsoft has a detailed documentation about it but here I try to explain in a more relatable way.

App registrations are identities for applications. Rather than verifying a users identity, we can delegate some permissions to an app identity.

Creating app registration in Azure means you trust Microsoft Identity to manage authentication of your app.

Creating an App Registration in Azure Active Directory generates a service principal that can be utilized with other Azure services.

This process provides you with a client ID (application ID), object ID, tenant ID, and the option to generate a client secret or assign a public key.

The service principal created from this process is the Application type. There are other types of service principals: Managed Identity & Legacy.

In your business logic (code), you can then use a private key or the client secret to enable your application to authenticate as a service principal to access resources on the resource server

The above diagram shows the process for an implicit flow.

-          End user(resource owner) wants to access a data on the resource server (Dataverse, db server of web apps, facebook backend).

-       End user uses  a client (mobile app, facebook front end app, website etc) to do this.

-         Client can use google, facebook, or user-name/password etc it all ties into one AAD.

-          The resource server receives the request but redirects to the authz server because it trusts it. And says I am going to need a token

-          Client sends clientid,scopes,redirectionurl, to the authz srver

-          If the user is not already authenticated, it’s going to prompt them to do so, and consent (consent this app1 for these permisisons in the scope)

-          If yes, the authz server sends the client a auth code

-          If there is a rediection url, the code is sent to it.

-          Client sends the auth code, secret, client id

-          Authz sends back access token

-          For implicit flows, the above four steps do not happen, the authz server sends an access token directly to client instead.

-          The client sends this auth token & request to the resource server and the response is returned after it verifies with the authz server.

Service Principals are of three types:

Application - This type of service principal is the local representation, or application instance, of a global application object in a single tenant or directory. This is the one that is created when you create in Azure Portal.

Managed Identity: A special type of service principal that does not have an application tied to it. It is tied to a resource instead and based on role-based access control (RBAC). For example, a managed identity can be created for a virtual machine, azure service bus etc.

Legacy - This type of service principal represents a legacy app, which is an app created before app registrations were introduced or an app created through legacy experiences.

Next post will be about Managed Identity.

That’s all for today & have a nice day.