Application, Service Principal & Consentement

Maintenant que nous avons vu la notion de modern authentication, passons en revue les principaux concepts d’Azure Active Directory nécessaires à votre authentification moderne.

Nous tenterons ici d’éclaircir deux concepts importants autour de l’authentification des applications avec Azure AD. Nous parlerons donc d’applications au sens Azure AD puis de leur représentation concrète avec les “Service Principals” (ou “principaux de service” en français, ce qui, je vous l’accorde ne nous aide pas vraiment à comprendre ce que c’est).

Inscription d’application

Il s’agit de la définition ou du manifeste de l’application : il est déclaré dans un seul Azure AD (celui hébergeant l’application en général) et comporte toutes les informations nécessaires à l’authentification de cette application. On y retrouve donc des informations d’ordre général (nom, organisation, logo, url…), ses identifiants et secrets, les types d’authentifications prises en charge (flow OAuth, token…) ainsi que les permissions d’API nécessaires à son fonctionnement.

Comme l’application est une définition, on ne l’utilise donc jamais directement. Si vous êtes familier du développement orienté objet, vous pouvez assimiler l’application comme la déclaration de classe. Pour utiliser cette classe, il faut l’instancier dans votre programme. Dans cette image, le programme serait votre tenant Azure AD et l’objet instancié le Service Principal.

Service Principal

Il s’agit de la représentation concrète de l’application au sein de l’Azure AD. Les principaux représentent les identités d’une entité (application, user…) au sein d’un Active Directory. C’est sur cette entité que sont affectés les droits (RBAC) ainsi que les consentements d’autorisation OAuth. Il est créé automatiquement dans l’Azure AD hébergeant l’application (ce qui est souvent à l’origine de la confusion avec l'”Application”). Dans le cas d’une application multi tenant (même application utilisée dans plusieurs tenants), un Service Principal est créé sur chaque tenant ayant “consenti” l’application. On retrouve l’ensemble de ces “Service Principals” dans la partie “Application d’entreprise”.

Le portail Azure ne nous aide pas vraiment à ne pas nous tromper entre “Service Principal” et “Application”. Pour éviter toute confusion, voici ce qu’il faut lire dans la barre latérale du composant Azure AD sur le portail :

Permissions et consentement

Lors de l’utilisation d’une application au sein de l’Azure AD, il est souvent nécessaire d’accéder à certaines informations fournies par des APIs (Microsoft ou autres). Dans ce cas, il sera nécessaire de les déclarer lors de l’inscription de l’application puis de les faire accepter (consent) par le propriétaire de la ressource cible (admin du tenant ou utilisateur). En effet, comme vu précédemment, les autorisations OAuth2 étant attachées soit à une application soit à une identité composite (application + utilisateur), toutes ces combinaisons d’identité et de droits doivent être consenties. Chaque fournisseur de données (resource provider) détermine ses niveaux de droits et de consentement requis. Ces derniers sont définis par leur scope (ID URI) sur lesquels s’appliquent  ces droits.

Les permissions peuvent donc être de deux types :

• Déléguées : l’application présentera un jeton d’accès combinant l’identité de l’application et celle d’un utilisateur connecté, ce dernier consent les droits d’accès en son nom. Parfois, le consentement d’un administrateur peut être requis
• Application : l’application présentera un jeton d’accès avec sa seule identité. Seul un administrateur du tenant peut consentir les accès.

=> Les permissions effectives du jeton représentent le privilège le moins élevé entre ces permissions et celle de l’utilisateur connecté (s’il y a).

Et pour continuer cette série spéciale Identité, nous vous invitons à consulter notre article sur l’implicit flow.