Authentication difference between using AAD app key and Service Principal Password

Question

To run applications in Azure, I need to create an Application in Azure AD and a corresponding Service Principal. Then my application authenticates against this App/Principal pair. To authenticate, I can create an application key in the App registration, or I can create a password in the Service Principal (among other options). What's the difference from a practial standpoint?

For example, this code runs exactly the same (from the outside) whether the $key is the App's key or the Service Principal's password:

    $key = ConvertTo-SecureString $authKeyOrPassword -AsPlainText -Force
    $cred = New-Object System.Management.Automation.PSCredential($appID, $key)
    Add-AzureRmAccount -Credential $cred -TenantId $tenantID -ServicePrincipal

When should I authenticate against the App, and when should I use the Service Principal?

Thorpe

Answer 1

First, let me explain why it has both Applications and service principals in Azure AD. Here is the explanation from Mordent Authentication with Azure AD for Web App by Vittorio Bertocci.

Azure AD defines a new entity, the Application, which is meant to describe an application as an abstract entity: a template, if you will. As a developer, you work with Applications. At deployment time a given Application object can be used as a blueprint to create a ServicePrincipal representing a concrete instance of an application in a directory. It’s that ServicePrincipal that is used to define what the app can actually do in that specific target directory, who can use it, what resources it has access to, and so on.

Bear with me just a little longer, the abstract part is almost over. The main way through which Azure AD creates a ServicePrincipal from an Application is consent. Here’s a simplified description of the flow: Say that you create an Application object in directory A, supplying all the protocol coordinates we’ve discussed so far in earlier chapters. Say that a user from tenant B navigates to the app’s pages and triggers an authentication flow. Azure AD authenticates the user from B against its home directory, B. In so doing, it sees that there is no ServicePrincipal for the app in B; hence, it prompts the user about whether he or she wants to consent for that app to have access to the directory B (you’ll see later in what capacity). If the user grants consent, Azure AD uses the Application object in A as a blueprint for creating a ServicePrincipal in B. Along with that, B records that the current user consented to the use of this application (expect lots of details on this later on). Once that’s done, the user receives a token for accessing the app.

If you want to know the difference between Azure AD App key and service principle Password, you'd better know the relationship of Application and service principal. I will copy&paste here some extracts from this page of the documentation

1. When you register an Azure AD application in the Azure portal, two objects are created in your Azure AD tenant: an application object, and a service principal object.

2. Consider the application object as the global representation of your application for use across all tenants, and the service principal as 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.

3. An application object therefore has a 1:1 relationship with the software application, and a 1:many relationships with its corresponding service principal object(s).A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant.

Example diagram

Summary

Now, we can know the difference between Azure AD App key and service principle password. They belong to different objects. The password to be associated with the service principal. This is just for the application tenant to login azure. However, you can provide the App key value with the application ID to log in as the application with all tenants.

To see more details about Application and service principal objects in Azure Active Directory , you can refer to this document.

Unwinking

Thanks! So are the following inferences correct? 1) if I want to lock down the permissions of a given process, would it be best to have it authenticate via it's own service principal instead of via the app key? 2) Is the primary purpose of an app key to provide a means for service principals in other tenants to authenticate to the app? If it is, I think it would be a misuse of the app key to use it directly for authentication (as in my code sample above). If not, what's it's purpose? – Thorpe

Hi, @Thorpe , For your extra questions, I have these opinions: 1)I think that it's for different scenes not permissions. 2) If you want to use service principle, you can create a key for your App or not.When you want to configure your app as a Client app to access WebAPIs, you need app keys. – Unwinking

This document may also be helpful to you.learn.microsoft.com/en-us/azure/active-directory/develop/… – Unwinking

Hi,@Thorpe , If this answer is helpful to you, please mark it as answer to help more people.Thanks! – Unwinking

This helps with background info, but I still don't understand in what scenarios I would use which option. – Thorpe

Hi @Thorpe Sorry for my unclear answer. the Key is only for the Client application to access WebAPIs. If your application is not as Client app, it would not need/have the key. Example: when you register your app as a Native app, it would not have Key. Service principle does not need this key to login azure as a application. – Unwinking