Azure: Service Accounts vs Service Principals

What Are Service Accounts?

User accounts are used by real users, service accounts are used by system services such as web servers, mail transport agents, databases etc. 

By convention, and only by convention, service accounts have user IDs in the low range, e.g. < 1000 or so. Except for UID 0, service accounts don't have any special privileges. Service accounts may - and typically do - own specific resources, even device special files, but they don't have superuser-like privileges.

A service account is essentially a privileged user account used to authenticate using a username and password. And, if used with automation, a service account is most likely excluded from any conditional access policies or multi-factor authentication.

What Are Service Principals?

A Service Principal, in simple terms, is a service account. But in Azure, there are two types of authentication available for service principals: password-based authentication (application secret) and certificate-based authentication. We recommend using a certificate, but you can also create an application secret.

Password-based authentication – You can compare a client secret to a long & complex password which is generated for you. Although you can connect as the Service Principal by filling, for example a PowerShell credential with the AppID and client secret, you cannot simply go to https://portal.azure.com and provide the values to interactively log in as the Service Principal. Which, from a security point of view, is a good thing.

Certificate-based authentication – This allows you to ‘link’ a certificate to the Service Principal which you can use for authentication. 

Read more: https://learn.microsoft.com/en-us/powershell/azure/create-azure-service-principal-azureps?view=azps-9.1.0