I want to share today how these two concepts / resources are tied together. (There are details out there on how to create an App Registration and Service Principal so I will not get into that.)
When a mobile/web application wants to do something in Azure (e.g. Access Microsoft Graph to log in, access a resource in Azure etc.) it needs to have an App Registration and a Service Principal associated to it.
What is App Registration?
You can think of App Registration as a resource metadata that the Service Principal looks at. This metadata determines which permissions the applications can have (or which permissions are the users granting the applications).
It stores credentials so when an application tries to access the resource it needs to match the credentials inside the App Registration. It can also store Redirect URIs so the App Registration can send the claims only to the listed URIs.
For example, even if your credentials have been compromised if a potential hacker does not know the redirect URI(s) the App Registration will not send out the claims and the attempt to access the resources will fail.
What is Service Principal?
In short, Service Principal is the 'mother' object that's in the AAD that actually goes and does something in the tenant based on the grants and the consent from the associated App Registration. Here's the official document
So, for example...
A user is trying to login to an application to access some resource within Azure.
The App Rego (an Aussie lingo.. lol) that's tied to that application will "talk" to the associated Service Principal.
As I mentioned before App Rego is like a metadata. Which itself cannot communicate with the directory. It needs to "ask" the associated Service Principal (SP for short) "Hey, associated SP! Would you be able to go and log this user in for me so I can send them somewhere?"
SP checks to see if the App Rego is actually authorized to do the things (based on which permissions were granted either through delegated or application permission) it's asking to do.
The SP will go to the directory and checks the user against the directory to see if the user is valid. If the user is indeed a valid user, SP sends the attribute of that user back to the App Rego.
The App Rego then says, "Thanks mate!" then sends that information over to the resource that the web application is wanting to communicate with.
(I put quotation around the 'talk' and 'ask' since the App Registration doesn't actually communicate. Think of App Registration as more like a job description for the Service Principal to act upon. And the AAD will not allow the Service Principal to do ANY work outside of that job description.)
Hope this was helpful!
I know this is a very very short and brief description but I hope this helps those who are new to this and just as lost as I was when I first learnt about these concepts.
(Wait... You may be wondering.. why the need for the metadata?)
- Why Microsoft did it this way makes more sense when we understand multi-tenancy. I will put out a short article on that soon!
Top comments (0)