Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Différence entre "enterprise application" et "app registration" dans Azure

ayi

Différence entre “enterprise application” et “app registration” dans Azure

ayi_2

Une App Registration (inscription d’application) est un moyen de réserver votre application et votre URL auprès d’Azure AD, lui permettant de communiquer avec Azure AD, de configurer vos URL de réponse et d’activer les services AAD dessus. Lorsque vous avez une application que vous développez et que vous souhaitez intégrer avec Azure, vous devez enregistrer votre application dans App Registrations, où vous configurerez votre URL de réponse, votre URL de déconnexion et l’accès API si nécessaire. Lorsque vous enregistrez votre application, Azure AD lui attribue un identifiant d’application unique et vous permet d’ajouter certaines capacités telles que les identifiants, les permissions et les connexions. Les paramètres par défaut permettent uniquement aux utilisateurs du locataire sous lequel votre application est enregistrée de se connecter à votre application.
Le panneau Enterprise Applications peut être confondu avec App Registrations car le panneau Enterprise Application contient la liste de vos principaux de service. Cependant, le terme Enterprise App (application d’entreprise) fait généralement référence aux applications publiées par d’autres entreprises dans la galerie AAD qui peuvent être utilisées au sein de votre organisation. Par exemple, si vous souhaitez intégrer <a href="https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/workplacebyfacebook-tutorial">Facebook</a> et gérer le SSO au sein de votre organisation, vous pouvez l’intégrer depuis le menu déroulant Enterprise Applications dans le panneau des applications. Vos propres applications seront également représentées dans le panneau Enterprise Applications en tant que principaux de service, qui sont des instanciations de vos applications dans le locataire.
App Registration : <a href="https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v1-add-azure-ad-app">https://learn.microsoft.com/en-us/azure/active-directory/develop/quickstart-v1-add-azure-ad-app</a>
Intégration d’une application d’entreprise (G-Suite) : <a href="https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/google-apps-tutorial">https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/google-apps-tutorial</a>

AyiNEDJIMI

Bonjour,
La distinction entre Enterprise Application et App Registration dans Azure Active Directory (maintenant appelé Microsoft Entra ID) est l’une des questions les plus fréquentes et les plus source de confusion pour les développeurs et administrateurs Azure. Ces deux concepts sont liés mais jouent des rôles fondamentalement différents. Je vais vous expliquer en détail cette relation et leurs usages respectifs.
<h2><a name="p-34584-la-relation-fondamentale-application-vs-principal-de-service-1" class="anchor" href="#p-34584-la-relation-fondamentale-application-vs-principal-de-service-1" aria-label="Heading link"></a>La relation fondamentale : Application vs Principal de service</h2>
Pour bien comprendre, il faut partir d’une analogie :
<ul>
<li>L’App Registration (Inscription d’application) est comme le passeport de votre application — c’est sa définition d’identité globale dans votre tenant (ou dans le tenant de l’éditeur).</li>
<li>L’Enterprise Application (Application d’entreprise), aussi appelée Service Principal, est comme le visa — c’est l’instance de cette identité dans un tenant spécifique, avec les permissions accordées localement.</li>
</ul>
<h3><a name="p-34584-le-modle-objet-dazure-ad-2" class="anchor" href="#p-34584-le-modle-objet-dazure-ad-2" aria-label="Heading link"></a>Le modèle objet d’Azure AD</h3>
<pre><code class="lang-auto">Tenant A (éditeur) Tenant B (client)
┌─────────────────────────────┐ ┌──────────────────────────────┐
│ App Registration │ 1:N │ Enterprise Application │
│ (Application object) │──────>│ (Service Principal object) │
│ │ │ │
│ - Application ID (client) │ │ - Object ID (local) │
│ - Secrets / Certificats │ │ - Permissions accordées │
│ - Redirect URIs │ │ - Assignments utilisateurs │
│ - Manifest de l'app │ │ - Paramètres SSO │
└─────────────────────────────┘ └──────────────────────────────┘
</code></pre>
Règle fondamentale : Pour chaque App Registration dans un tenant, il existe automatiquement une Enterprise Application correspondante dans ce même tenant. Quand une autre organisation consent à utiliser votre application multi-tenant, une Enterprise Application est créée dans leur tenant.
<h2><a name="p-34584-app-registration-en-dtail-3" class="anchor" href="#p-34584-app-registration-en-dtail-3" aria-label="Heading link"></a>App Registration en détail</h2>
<h3><a name="p-34584-quest-ce-quune-app-registration-4" class="anchor" href="#p-34584-quest-ce-quune-app-registration-4" aria-label="Heading link"></a>Qu’est-ce qu’une App Registration ?</h3>
L’App Registration représente l’objet application global — c’est la définition de ce qu’est votre application, ses capacités et ses besoins en termes d’identité.
Où la trouver : Azure Portal > Microsoft Entra ID > Inscriptions d’applications
<h3><a name="p-34584-ce-que-vous-configurez-dans-app-registration-5" class="anchor" href="#p-34584-ce-que-vous-configurez-dans-app-registration-5" aria-label="Heading link"></a>Ce que vous configurez dans App Registration</h3>
1. Identité de l’application
<ul>
<li>Application (client) ID : l’identifiant unique de l’application (GUID)</li>
<li>Directory (tenant) ID : le tenant propriétaire</li>
<li>Object ID : l’ID de l’objet application dans le répertoire</li>
</ul>
2. Authentification
<ul>
<li>Redirect URIs : les URLs de callback après authentification</li>
<li>Plateforme : Web, SPA, Desktop, Mobile</li>
<li>Implicit flow, Authorization code flow avec PKCE</li>
<li>Logout URL</li>
</ul>
3. Certificats et secrets
<pre data-code-wrap="powershell"><code class="lang-powershell"># Créer un secret d'application via PowerShell
$app = Get-AzADApplication -ApplicationId "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$secret = New-AzADAppCredential -ApplicationId $app.AppId -EndDate (Get-Date).AddYears(1)
Write-Output "Secret Value (à sauvegarder maintenant) : $($secret.SecretText)"
</code></pre>
4. Permissions API (ce que l’application demande)
<ul>
<li>Delegated permissions : agit au nom d’un utilisateur connecté</li>
<li>Application permissions : agit en son propre nom (daemon/service)</li>
</ul>
<pre data-code-wrap="powershell"><code class="lang-powershell"># Ajouter une permission API via Azure CLI
az ad app permission add \
--id "votre-app-id" \
--api "00000003-0000-0000-c000-000000000000" \ # Microsoft Graph
--api-permissions "User.Read=Scope" # Permission déléguée
</code></pre>
5. Expose an API (ce que l’application expose)
<ul>
<li>Définition des scopes personnalisés</li>
<li>Application ID URI (ex: <code>api://votre-app-id</code>)</li>
</ul>
6. Owners et App Roles
<h3><a name="p-34584-qui-gre-les-app-registrations-6" class="anchor" href="#p-34584-qui-gre-les-app-registrations-6" aria-label="Heading link"></a>Qui gère les App Registrations ?</h3>
Typiquement, les développeurs et les architectes d’identité gèrent les App Registrations. Il faut le rôle Application Developer ou Global Administrator dans Azure AD.
<h2><a name="p-34584-enterprise-application-en-dtail-7" class="anchor" href="#p-34584-enterprise-application-en-dtail-7" aria-label="Heading link"></a>Enterprise Application en détail</h2>
<h3><a name="p-34584-quest-ce-quune-enterprise-application-8" class="anchor" href="#p-34584-quest-ce-quune-enterprise-application-8" aria-label="Heading link"></a>Qu’est-ce qu’une Enterprise Application ?</h3>
L’Enterprise Application (Service Principal) représente l’instance locale d’une application dans un tenant spécifique. C’est ici que se gère qui peut utiliser l’application et quelles permissions ont été accordées.
Où la trouver : Azure Portal > Microsoft Entra ID > Applications d’entreprise
<h3><a name="p-34584-ce-que-vous-configurez-dans-enterprise-application-9" class="anchor" href="#p-34584-ce-que-vous-configurez-dans-enterprise-application-9" aria-label="Heading link"></a>Ce que vous configurez dans Enterprise Application</h3>
1. Propriétés générales
<ul>
<li>Activation/désactivation pour les utilisateurs</li>
<li>Visibilité dans le portail My Apps</li>
<li>Logo et informations d’affichage</li>
</ul>
2. Gestion des utilisateurs et groupes (Assignments)
<pre data-code-wrap="powershell"><code class="lang-powershell"># Assigner un utilisateur à une Enterprise Application
$servicePrincipal = Get-AzADServicePrincipal -ApplicationId "votre-app-id"
$user = Get-AzADUser -UserPrincipalName "utilisateur@domain.com"

New-AzADServicePrincipalAppRoleAssignment -ServicePrincipalId $servicePrincipal.Id
-PrincipalId $user.Id -ResourceId $servicePrincipal.Id
-AppRoleId "00000000-0000-0000-0000-000000000000" # Default role
</code></pre>
3. Single Sign-On (SSO)
<ul>
<li>SAML : pour l’intégration avec des applications tierces</li>
<li>OIDC/OAuth2 : pour les applications modernes</li>
<li>Password-based SSO : pour les applications legacy</li>
<li>Linked : pour les applications avec SSO externe existant</li>
</ul>
4. Provisionnement automatique (SCIM)
<ul>
<li>Synchronisation automatique des utilisateurs vers l’application</li>
<li>Désactivation automatique lors du départ d’un employé</li>
</ul>
5. Permissions accordées (Consent)
<pre data-code-wrap="powershell"><code class="lang-powershell"># Accorder le consentement administrateur pour une permission
az ad app permission admin-consent --id "votre-app-id"

Lister les permissions accordées

az ad app permission list-grants --id "votre-app-id"
</code></pre>
6. Conditional Access
<ul>
<li>Application de politiques d’accès conditionnel</li>
<li>Exigence de MFA, conformité des appareils, etc.</li>
</ul>
<h3><a name="p-34584-qui-gre-les-enterprise-applications-10" class="anchor" href="#p-34584-qui-gre-les-enterprise-applications-10" aria-label="Heading link"></a>Qui gère les Enterprise Applications ?</h3>
Typiquement, les administrateurs IT et les gestionnaires d’identité gèrent les Enterprise Applications. Les rôles Cloud Application Administrator ou Global Administrator sont nécessaires.
<h2><a name="p-34584-tableau-comparatif-synthtique-11" class="anchor" href="#p-34584-tableau-comparatif-synthtique-11" aria-label="Heading link"></a>Tableau comparatif synthétique</h2>
<div class="md-table">
<table>
<thead>
<tr>
<th>Aspect</th>
<th>App Registration</th>
<th>Enterprise Application</th>
</tr>
</thead>
<tbody>
<tr>
<td>Autre nom</td>
<td>Application object</td>
<td>Service Principal</td>
</tr>
<tr>
<td>Portée</td>
<td>Globale (multi-tenant possible)</td>
<td>Locale au tenant</td>
</tr>
<tr>
<td>Propriétaire</td>
<td>Développeurs / ISV</td>
<td>Administrateurs IT</td>
</tr>
<tr>
<td>Configure</td>
<td>Ce QUE fait l’app</td>
<td>QUI utilise l’app</td>
</tr>
<tr>
<td>Existence</td>
<td>Dans le tenant propriétaire</td>
<td>Dans chaque tenant utilisant l’app</td>
</tr>
<tr>
<td>Secrets/Certs</td>
<td>Oui</td>
<td>Non</td>
</tr>
<tr>
<td>SSO Config</td>
<td>Non</td>
<td>Oui</td>
</tr>
<tr>
<td>User Assignment</td>
<td>Non</td>
<td>Oui</td>
</tr>
<tr>
<td>Consent</td>
<td>Demande les permissions</td>
<td>Reçoit le consentement</td>
</tr>
<tr>
<td>Conditional Access</td>
<td>Non</td>
<td>Oui</td>
</tr>
<tr>
<td>SCIM Provisioning</td>
<td>Non</td>
<td>Oui</td>
</tr>
</tbody>
</table>
</div><h2><a name="p-34584-cas-pratiques-quand-utiliser-quoi-12" class="anchor" href="#p-34584-cas-pratiques-quand-utiliser-quoi-12" aria-label="Heading link"></a>Cas pratiques : quand utiliser quoi ?</h2>
<h3><a name="p-34584-scnario-1-dvelopper-une-nouvelle-application-13" class="anchor" href="#p-34584-scnario-1-dvelopper-une-nouvelle-application-13" aria-label="Heading link"></a>Scénario 1 : Développer une nouvelle application</h3>
Vous développez une application web qui s’authentifie avec Azure AD :
<ol>
<li>Créez une App Registration pour définir votre application</li>
<li>Configurez les Redirect URIs, les permissions Microsoft Graph nécessaires</li>
<li>Récupérez le <code>client_id</code> et <code>tenant_id</code> pour votre code</li>
<li>Une Enterprise Application est créée automatiquement dans votre tenant</li>
</ol>
<h3><a name="p-34584-scnario-2-intgrer-une-application-saas-tierce-ex-salesforce-servicenow-14" class="anchor" href="#p-34584-scnario-2-intgrer-une-application-saas-tierce-ex-salesforce-servicenow-14" aria-label="Heading link"></a>Scénario 2 : Intégrer une application SaaS tierce (ex: Salesforce, ServiceNow)</h3>
L’administrateur IT configure l’accès SSO :
<ol>
<li>Dans Enterprise Applications, cliquez sur “+ Nouvelle application”</li>
<li>Cherchez l’application dans la galerie Azure AD</li>
<li>Configurez le SSO SAML</li>
<li>Assignez les utilisateurs et groupes</li>
<li>Activez le provisionnement SCIM si disponible</li>
</ol>
Ici, aucune App Registration n’est créée par l’administrateur — l’éditeur du SaaS l’a déjà fait dans son tenant.
<h3><a name="p-34584-scnario-3-servicedaemon-sans-utilisateur-client-credentials-flow-15" class="anchor" href="#p-34584-scnario-3-servicedaemon-sans-utilisateur-client-credentials-flow-15" aria-label="Heading link"></a>Scénario 3 : Service/Daemon sans utilisateur (Client Credentials Flow)</h3>
<pre data-code-wrap="python"><code class="lang-python"># Authentification d'un service sans utilisateur
import msal

app = msal.ConfidentialClientApplication(
client_id="votre-client-id", # Depuis App Registration
client_credential="votre-secret", # Depuis App Registration
authority=f"https://login.microsoftonline.com/{tenant_id}"
)

result = app.acquire_token_for_client(
scopes=["https://graph.microsoft.com/.graph.default"]
)
</code></pre>
Pour ce cas :
<ul>
<li>App Registration : configure le secret et la permission Application (ex: <code>User.Read.All</code>)</li>
<li>Enterprise Application : l’admin accorde le consentement administrateur</li>
</ul>
<h2><a name="p-34584-la-confusion-courante-mme-objet-deux-vues-16" class="anchor" href="#p-34584-la-confusion-courante-mme-objet-deux-vues-16" aria-label="Heading link"></a>La confusion courante : même objet, deux vues</h2>
Quand vous créez une App Registration, vous voyez deux entrées dans Azure AD :
<ul>
<li>Une dans “Inscriptions d’applications” (App Registration)</li>
<li>Une dans “Applications d’entreprise” (Enterprise Application)</li>
</ul>
Ce sont deux vues différentes du même objet applicatif. Vous pouvez naviguer entre elles via le portail. Si vous supprimez l’App Registration, la Enterprise Application correspondante est également supprimée.
<hr>
Pour résumer : pensez à l’App Registration comme la carte d’identité de votre application (qui elle est, ce dont elle a besoin), et à l’Enterprise Application comme le contrat d’utilisation dans votre organisation (qui peut l’utiliser, avec quelles permissions, sous quelles conditions).
N’hésitez pas à me poser des questions sur un scénario spécifique — configuration SSO, gestion des permissions, ou implémentation d’un flux d’authentification particulier. Je suis là pour vous aider à approfondir n’importe quel aspect de la gestion des identités Azure AD.