Jeton daccès c

Types

d’applications

Comme expliqué dans la section Scénarios, il existe de nombreuses façons d’acquérir un jeton avec MSAL.NET. Certains nécessitent une interaction et d’autres sont totalement transparents pour l’utilisateur. L’approche utilisée pour acquérir un jeton diffère selon que le développeur crée un client public (de bureau ou mobile) ou une application cliente confidentielle (application web, API web ou démon tel qu’un service Windows). Les clients publics nécessitent généralement l’interaction de l’utilisateur, tandis que les clients confidentiels s’appuient sur des informations d’identification pré-provisionnées, telles que des certificats et des secrets.

Mise en cache des jetons

Pour les applications clientes publiques et confidentielles, MSAL.NET prend en charge l’ajout d’un cache de jetons qui conserve les jetons d’authentification et d’actualisation, ainsi que les actualise de manière proactive en fonction des besoins. Pour plus d’informations, consultez Sérialisation du cache de jeton dans MSAL.NET.

Pour les applications de bureau .NET (.NET, .NET Framework et .NET Core), l’application doit gérer directement la sérialisation et le stockage du cache de jetons. Toutefois, des classes d’assistance sont disponibles pour simplifier le processus.

Méthodes d’acquisition de jetons

Les applications clientes publiques

• acquièrent souvent des jetons de manière interactive, en demandant à l’utilisateur de se connecter.
• Il est également possible pour une application de bureau s’exécutant sur une machine Windows jointe à un domaine ou à Microsoft Entra ID d’utiliser l’authentification Windows intégrée (IWA/Kerberos) pour acquérir un jeton en mode silencieux.
  • Gardez à l’esprit que l’approche IWA n’est pas recommandée . Une approche plus sécurisée à l’aide du Web Account Manager (WAM) est disponible.
• Pour les applications de bureau .NET Framework, dans des scénarios limités, il est possible d’obtenir un jeton avec un nom d’utilisateur et un mot de passe. Pour des raisons de sécurité, cette approche n’est pas recommandée.
• Dans les applications exécutées sur des appareils qui n’ont pas de navigateur Web, un jeton peut être acquis à l’aide du flux de code de l’appareil, qui fournit à l’utilisateur de l’application une URL et un code. L’utilisateur se rendra ensuite sur un navigateur Web sur un autre appareil, entrera le code et se connectera. L’appareil d’authentification interroge ensuite les services Microsoft Entra ID jusqu’à ce qu’il reçoive la confirmation d’une connexion réussie et un jeton d’accès.

Le tableau suivant récapitule les approches disponibles pour l’acquisition de jetons dans les applications clientes publiques :

Web

Système d’exploitation	Plate-forme	Type d’application	Interactive	IWA	Code de périphérique
Windows (desktop)	.NET	Ordinateur de bureau (WPF, Windows forms, console)	✅	✅	✅
Android	.NET MAUI	Mobile	✅	❌	❌
iOS	.NET MAUI	Mobile	✅	❌	✅
macOS, Linux, Windows	.NET Core	Console	N/A Voir Utilisation des navigateurs	✅	✅

Applications clientes

• confidentielles Acquiert un jeton pour l’application elle-même , et non pour un utilisateur. L’acquisition de jetons se fait à l’aide des informations d’identification du client. Ce flux est utile pour synchroniser des outils ou des outils qui traitent des données ou des informations sur l’utilisateur sans identité qui lui est attachée.
• Pour les API web appelant une API au nom d’un utilisateur, les développeurs peuvent utiliser le flux Au nom de. L’application elle-même utilisera les informations d’identification du client pour acquérir un jeton basé sur une assertion de l’utilisateur (par exemple, SAML ou JWT). Ce flux peut être utilisé pour les applications qui ont besoin d’accéder aux ressources d’un utilisateur particulier dans le cadre d’appels de service à service.
• Pour les applications web , l’acquisition du jeton s’effectue à l’aide d’un code d’autorisation après la connexion de l’utilisateur via l’URL de la demande d’autorisation. Il s’agit généralement du mécanisme utilisé par une application qui permet à l’utilisateur de se connecter à l’aide d’OpenID Connect, puis d’accéder aux API Web pour le compte de cet utilisateur particulier.

Le tableau suivant récapitule les méthodes d’acquisition de jetons dans les applications clientes confidentielles :

Web principale Web .NET Framework Core

Système d’exploitation			Code	d’authentification du	client
Windows	.NET Framework	Application Web	✅	❌	✅
Windows, macOS, Linux	ASP.NET Application		✅	❌	✅
Windows		API	✅	✅	❌
Windows, macOS, Linux	ASP.NET API	Web	✅	✅	❌
Windows	.NET Framework	Daemon (service Windows)	✅	❌	❌
Windows, macOS, Linux	.NET Core	Daemon	✅	❌	❌

Modèle d’acquisition de jetons dans MSAL.NET

Toutes les méthodes Acquire Token de MSAL.NET ont le modèle suivant :

• Depuis l’application, vous appelez la méthode AcquireToken XXX correspondant au flux que vous souhaitez utiliser, en passant les paramètres obligatoires de ce flux (en général)
• Cela renvoie un générateur de commandes, sur lequel vous pouvez ajouter des paramètres facultatifs à l’aide de . Avec les méthodes YYY,
• vous appelez ensuite ExecuteAsync() pour obtenir le résultat de votre authentification.

Voici le modèle :

propriétés dans MSAL.NET

Dans tous les cas ci-dessus, les méthodes d’acquisition de jetons renvoient un (ou dans le cas des méthodes asynchrones un .

Dans MSAL.NET, AuthenticationResult expose :

• pour que l’API Web puisse accéder aux ressources. Il s’agit d’une chaîne, généralement un JWT encodé en base64, mais le client ne doit jamais regarder à l’intérieur du jeton d’accès. Il n’est pas garanti que le format reste stable et qu’il soit chiffré pour la ressource. Les personnes qui écrivent du code en fonction du contenu du jeton d’accès sur le client sont l’une des plus grandes sources d’erreurs et les ruptures de logique du client
• pour l’utilisateur (il s’agit d’un JWT)
• indiquent la date et l’heure d’expiration du jeton
• et contiennent le locataire dans lequel l’utilisateur a été trouvé. Notez que dans le cas d’utilisateurs invités (scénarios Microsoft Entra B2B), le TenantId est le locataire invité, et non le locataire unique. Lorsque le jeton est livré au nom d’un utilisateur, il contient également des informations sur cet utilisateur. Pour les flux clients confidentiels où les jetons sont demandés sans utilisateur (pour l’application), ces informations utilisateur sont nulles.
• L’ID unique de l’utilisateur pour lequel le jeton a été émis (voir Étendues et non ressources).

MSAL.NET définit la notion de Compte (par le biais de l’interface). Ce changement cassant apporte la bonne sémantique : le fait qu’un même utilisateur puisse avoir plusieurs comptes, dans différents annuaires Microsoft Entra. De plus, MSAL.NET fournit de meilleures informations dans le cas de scénarios d’invités, car les informations de compte d’accueil sont fournies. Le diagramme suivant illustre la structure de l’interface :

La classe identifie un compte dans un locataire spécifique. Il possède les propriétés suivantes :

Propriété	Description
Représentation de chaîne pour un GUID, qui est l’ID du locataire où réside le compte
Représentation de chaîne pour un GUID qui est l’ID de l’utilisateur qui possède le compte dans le locataire
Identificateur unique du compte (il s’agit de la concaténation de et séparés par une virgule et ne sont pas encodés en base64)

L’interface représente des informations sur un seul compte. Le même utilisateur peut être présent dans différents locataires, c’est-à-dire qu’un utilisateur peut avoir plusieurs comptes. Ses membres sont :

Propriété	Description
Chaîne contenant la valeur affichable au format UserPrincipalName (UPN), par exemple, [email protected]. Il peut s’agir de la valeur null, tandis que HomeAccountId et HomeAccountId.Identifier ne sont pas null. Cette propriété remplace la propriété de dans les versions précédentes de MSAL.NET.
Chaîne contenant le fournisseur d’identité de ce compte, pour exemple. Cette propriété remplace la propriété de , sauf qu’elle contenait également des informations sur le locataire (en plus de l’environnement cloud), alors qu’ici il ne s’agit que de l’hôte.
AccountId du compte d’accueil de l’utilisateur. Cela permet d’identifier de manière unique l’utilisateur dans les locataires Microsoft Entra.