Scénarios d’authentification pour Azure ADAuthentication scenarios for Azure AD

Azure Active Directory (Azure AD) simplifie l’authentification pour les développeurs en fournissant l’identité en tant que service, avec la prise en charge des protocoles standard tels que OAuth 2.0 et OpenID Connect, ainsi que des bibliothèques open source pour différentes plateformes afin de vous permettre de commencer à coder rapidement.Azure Active Directory (Azure AD) simplifies authentication for developers by providing identity as a service, with support for industry-standard protocols such as OAuth 2.0 and OpenID Connect, as well as open-source libraries for different platforms to help you start coding quickly. Cet article a pour but de vous aider à comprendre les différents scénarios pris en charge par Azure AD et vous montre comment prendre l’application en main.This article will help you understand the various scenarios Azure AD supports and show you how to get started. Il comprend les sections suivantes :It’s divided into the following sections:

Principes fondamentaux de l’authentification dans Azure ADBasics of authentication in Azure AD

Si vous ne connaissez pas les concepts de base de l’authentification dans Azure AD, lisez cette section.If you are unfamiliar with basic concepts of authentication in Azure AD, read this section. Sinon, vous pouvez l’ignorer et passer directement à la section Types d’application et scénarios.Otherwise, you may want to skip down to Application types and scenarios.

Prenons l’exemple du scénario le plus élémentaire dans lequel une identité est requise : un utilisateur doit s’authentifier auprès d’une application web dans un navigateur web.Let’s consider the most basic scenario where identity is required: a user in a web browser needs to authenticate to a web application. Ce scénario est décrit plus en détail dans la section Navigateur web vers application web, mais c’est un bon point de départ pour illustrer les fonctionnalités d’Azure AD et conceptualiser le fonctionnement du scénario.This scenario is described in greater detail in the Web browser to web application section, but it’s a useful starting point to illustrate the capabilities of Azure AD and conceptualize how the scenario works. Considérez le diagramme suivant pour ce scénario :Consider the following diagram for this scenario:

Vue d’ensemble de l’authentification des applications web

Voici ce que vous devez savoir sur les divers composants du diagramme ci-dessus :With the diagram above in mind, here’s what you need to know about its various components:

  • Azure AD est le fournisseur d’identité responsable de la vérification de l’identité des utilisateurs et applications de l’annuaire d’une organisation et, en fin de compte, de l’émission des jetons de sécurité après l’authentification correcte de ces utilisateurs et applications.Azure AD is the identity provider, responsible for verifying the identity of users and applications that exist in an organization’s directory, and ultimately issuing security tokens upon successful authentication of those users and applications.
  • Pour pouvoir externaliser l’authentification en la confiant à Azure AD, une application doit être inscrite dans Azure AD, qui l’inscrit et l’identifie de manière unique dans l’annuaire.An application that wants to outsource authentication to Azure AD must be registered in Azure AD, which registers and uniquely identifies the app in the directory.
  • Les développeurs peuvent utiliser les bibliothèques d’authentification open source d’Azure AD pour simplifier l’authentification en gérant les détails du protocole pour vous.Developers can use the open-source Azure AD authentication libraries to make authentication easy by handling the protocol details for you. Pour plus d’informations, voir Bibliothèques d’authentification d’Azure Active Directory.For more information, see Azure Active Directory Authentication Libraries.
  • Une fois qu’un utilisateur a été authentifié, l’application doit valider son jeton de sécurité pour s’assurer que l’authentification a réussi.Once a user has been authenticated, the application must validate the user’s security token to ensure that authentication was successful. Nous avons des exemples de ce que l’application doit faire dans divers langages et infrastructures sur GitHub .We have samples of what the application must do in a variety of languages and frameworks on GitHub. Si vous créez une application web en ASP.NET, voir le guide sur l’ajout d’infos d’identification pour une application web ASP.NET.If you're building a web app in ASP.NET, see the add sign-in for an ASP.NET web app guide. Si vous créez une ressource d’API web en ASP.NET, voir le guide de prise en main d’API web.If you’re building a web API resource in ASP.NET, see the web API getting started guide.
  • Le flux de demandes et réponses du processus d’authentification est déterminé par le protocole d’authentification utilisé, par exemple OAuth 2.0, OpenID Connect, WS-Federation ou SAML 2.0.The flow of requests and responses for the authentication process is determined by the authentication protocol that was used, such as OAuth 2.0, OpenID Connect, WS-Federation, or SAML 2.0. Ces protocoles sont présentés plus en détail dans l’article Protocoles d’authentification d’Azure Active Directory et dans les sections ci-dessous.These protocols are discussed in more detail in the Azure Active Directory authentication protocols article and in the sections below.

Note

Azure AD prend en charge les normes OAuth 2.0 et OpenID Connect, qui utilisent massivement les jetons porteurs, y compris des jetons porteurs représentés sous forme de JWT.Azure AD supports the OAuth 2.0 and OpenID Connect standards that make extensive use of bearer tokens, including bearer tokens represented as JWTs. Un jeton du porteur est un jeton de sécurité léger qui octroie l’accès à une ressource protégée au « porteur ».A bearer token is a lightweight security token that grants the “bearer” access to a protected resource. En ce sens, le « porteur » désigne toute partie qui peut présenter le jeton.In this sense, the “bearer” is any party that can present the token. Une partie doit certes d’abord s’authentifier auprès d’Azure AD pour recevoir le jeton porteur, mais si les mécanismes nécessaires à la sécurité du jeton lors de la transmission et du stockage ne sont pas en place, il peut être intercepté et utilisé par une partie non autorisée.Though a party must first authenticate with Azure AD to receive the bearer token, if the required steps are not taken to secure the token in transmission and storage, it can be intercepted and used by an unintended party. Bien que certains jetons de sécurité intègrent un mécanisme de protection contre l’utilisation par des parties non autorisées, les jetons porteurs n’en sont pas dotés et doivent donc être acheminés sur un canal sécurisé, par exemple à l’aide du protocole TLS (HTTPS).While some security tokens have a built-in mechanism for preventing unauthorized parties from using them, bearer tokens do not have this mechanism and must be transported in a secure channel such as transport layer security (HTTPS). Si un jeton du porteur est transmis en clair, une partie malveillante peut utiliser une attaque d’intercepteur afin de s’approprier le jeton et de l’utiliser pour accéder sans autorisation à une ressource protégée.If a bearer token is transmitted in the clear, a man-in-the-middle attack can be used by a malicious party to acquire the token and use it for an unauthorized access to a protected resource. Les mêmes principes de sécurité s’appliquent au stockage ou à la mise en cache des jetons porteurs pour une utilisation ultérieure.The same security principles apply when storing or caching bearer tokens for later use. Veillez systématiquement à ce que votre application transmette et stocke les jetons porteurs de manière sécurisée.Always ensure that your application transmits and stores bearer tokens in a secure manner. Pour en savoir plus sur les aspects de sécurité des jetons porteurs, consultez RFC 6750 Section 5.For more security considerations on bearer tokens, see RFC 6750 Section 5.

Maintenant que vous avez une vue d’ensemble des principes fondamentaux, lisez les sections ci-dessous pour comprendre comment l’approvisionnement fonctionne dans Azure AD et les scénarios courants qu’Azure AD prend en charge.Now that you have an overview of the basics, read the sections below to understand how provisioning works in Azure AD and the common scenarios that Azure AD supports.

Revendications dans les jetons de sécurité Azure ADClaims in Azure AD security tokens

Les jetons de sécurité (jetons d’accès et d’ID) émis par Azure AD contiennent des revendications, ou assertions d’informations, sur le sujet qui a été authentifié.Security tokens (access and ID tokens) issued by Azure AD contain claims, or assertions of information about the subject that has been authenticated. Ces revendications peuvent être utilisées par l’application pour différentes tâches.These claims can be used by the application for various tasks. Par exemple, des applications peuvent utiliser des revendications pour valider le jeton, identifier le client d’annuaire du sujet, afficher des informations sur l’utilisateur, déterminer l’autorisation du sujet, etc.For example, applications can use claims to validate the token, identify the subject's directory tenant, display user information, determine the subject's authorization, and so on. Les revendications présentes dans un jeton de sécurité dépendent du type de jeton, du type d’informations d’identification utilisées pour authentifier l’utilisateur et de la configuration de l’application.The claims present in any given security token are dependent upon the type of token, the type of credential used to authenticate the user, and the application configuration. Une brève description de chaque type de revendication émise par Azure AD est fournie dans le tableau ci-dessous.A brief description of each type of claim emitted by Azure AD is provided in the table below. Pour plus d’informations, voir Types de jeton et de revendication pris en charge.For more information, refer to Supported token and claim types.

RevendicationClaim DescriptionDescription
ID de l'applicationApplication ID Identifie l’application qui utilise le jeton.Identifies the application that is using the token.
AudienceAudience Identifie la ressource de destination du jeton.Identifies the recipient resource the token is intended for.
Référence de classe du contexte d’authentification de l’applicationApplication Authentication Context Class Reference Indique comment le client a été authentifié (client public par opposition à client confidentiel).Indicates how the client was authenticated (public client vs. confidential client).
Moment d’authentificationAuthentication Instant Enregistre la date et l’heure de l’authentification.Records the date and time when the authentication occurred.
Méthode d’authentificationAuthentication Method Indique comment le sujet du jeton a été authentifié (mot de passe, certificat, etc.).Indicates how the subject of the token was authenticated (password, certificate, etc.).
PrénomFirst Name Fournit le prénom de l’utilisateur tel qu’il est défini dans Azure AD.Provides the given name of the user as set in Azure AD.
GroupesGroups Contient les ID d’objets des groupes Azure AD dont l’utilisateur est membre.Contains object IDs of Azure AD groups that the user is a member of.
Fournisseur d’identitéIdentity Provider Enregistre le fournisseur d’identité qui a authentifié le sujet du jeton.Records the identity provider that authenticated the subject of the token.
Émis àIssued At Enregistre l’heure à laquelle le jeton a été émis, souvent utilisée pour l’actualisation du jeton.Records the time at which the token was issued, often used for token freshness.
ÉmetteurIssuer Identifie le service d’émission de jeton de sécurité qui a émis le jeton, ainsi que le client Azure AD.Identifies the STS that emitted the token as well as the Azure AD tenant.
NomLast Name Fournit le nom de l’utilisateur tel qu’il est défini dans Azure AD.Provides the surname of the user as set in Azure AD.
NOMName Fournit une valeur contrôlable de visu qui identifie le sujet du jeton.Provides a human readable value that identifies the subject of the token.
ID objetObject ID Contient un identificateur unique non modifiable du sujet dans Azure AD.Contains an immutable, unique identifier of the subject in Azure AD.
contrôleurRoles Contient les noms conviviaux des rôles d’application Azure AD qui ont été affectés à l’utilisateur.Contains friendly names of Azure AD Application Roles that the user has been granted.
ÉtendueScope Indique les autorisations accordées à l’application cliente.Indicates the permissions granted to the client application.
ObjetSubject Indique le principal sur lequel portent les assertions d’informations du jeton.Indicates the principal about which the token asserts information.
ID clientTenant ID Contient un identificateur unique non modifiable du client de l’annuaire qui a émis le jeton.Contains an immutable, unique identifier of the directory tenant that issued the token.
Durée de vie du jetonToken Lifetime Définit l’intervalle de temps pendant lequel un jeton est valide.Defines the time interval within which a token is valid.
Nom d’utilisateur principalUser Principal Name Contient le nom d’utilisateur principal du sujet.Contains the user principal name of the subject.
VersionVersion Contient le numéro de version du jeton.Contains the version number of the token.

Principes fondamentaux de l’inscription d’une application dans Azure ADBasics of registering an application in Azure AD

Toute application qui externalise l’authentification pour la confier à Azure AD doit être inscrite dans un annuaire.Any application that outsources authentication to Azure AD must be registered in a directory. Cette étape consiste à donner des informations sur votre application à Azure AD, y compris son URL, l’URL à laquelle les réponses doivent être envoyées après l’authentification, l’URI permettant d’identifier votre application, etc.This step involves telling Azure AD about your application, including the URL where it’s located, the URL to send replies after authentication, the URI to identify your application, and more. Ces informations sont obligatoires pour les raisons principales suivantes :This information is required for a few key reasons:

  • Azure AD a besoin de communiquer avec l’application lors de l’authentification ou de l’échange de jetons.Azure AD needs to communicate with the application when handling sign-on or exchanging tokens. Les informations échangées entre Azure AD et l’application sont les suivantes :The information passed between Azure AD and the application includes the following:

    • URI d’ID d’application : identificateur d’une application.Application ID URI - The identifier for an application. Cette valeur est envoyée à Azure AD lors de l’authentification afin d’indiquer pour quelle application l’appelant souhaite un jeton.This value is sent to Azure AD during authentication to indicate which application the caller wants a token for. Cette valeur est également incluse dans le jeton pour que l’application sache qu’il s’agit de la cible prévue.Additionally, this value is included in the token so that the application knows it was the intended target.
    • URL de réponse et URI de redirection : pour une API web ou une application web, l’URL de réponse correspond à l’emplacement auquel Azure AD envoie la réponse d’authentification qui inclut un jeton si l’authentification a réussi.Reply URL and Redirect URI - For a web API or web application, the Reply URL is the location where Azure AD will send the authentication response, including a token if authentication was successful. Pour une application native, l’URI de redirection est un identificateur unique vers lequel Azure AD redirige l’agent utilisateur dans une requête OAuth 2.0.For a native application, the Redirect URI is a unique identifier to which Azure AD will redirect the user-agent in an OAuth 2.0 request.
    • ID d’application : ID d’une application généré par Azure AD au moment de l’inscription de l’application.Application ID - The ID for an application, which is generated by Azure AD when the application is registered. Lors d’une demande de code d’autorisation ou de jeton, l’ID et la clé d’application sont envoyés à Azure AD lors de l’authentification.When requesting an authorization code or token, the Application ID and Key are sent to Azure AD during authentication.
    • Clé : clé envoyée avec un ID d’application lors de l’authentification auprès d’Azure AD en vue d’appeler une API web.Key - The key that is sent along with an Application ID when authenticating to Azure AD to call a web API.
  • Azure AD doit assurer que l’application dispose des autorisations nécessaires pour accéder à vos données d’annuaire, à d’autres applications de votre organisation, etc.Azure AD needs to ensure the application has the required permissions to access your directory data, other applications in your organization, and so on.

L’approvisionnement devient plus clair lorsque vous comprenez qu’il existe deux catégories d’applications que vous pouvez développer et intégrer avec Azure AD :Provisioning becomes clearer when you understand that there are two categories of applications that can be developed and integrated with Azure AD:

  • Application à client unique : une application à client unique est destinée à être utilisée dans une seule organisation.Single tenant application - A single tenant application is intended for use in one organization. Il s’agit généralement d’applications métiers écrites par un développeur d’entreprise.These are typically line-of-business (LoB) applications written by an enterprise developer. Une application à client unique doit être accessible uniquement aux utilisateurs d’un annuaire et, en conséquence, ne doit être approvisionnée que dans un seul annuaire.A single tenant application only needs to be accessed by users in one directory, and as a result, it only needs to be provisioned in one directory. Ces applications sont généralement inscrites par un développeur de l’organisation.These applications are typically registered by a developer in the organization.
  • Application mutualisée : une application mutualisée est destinée à être utilisée dans plusieurs organisations, non dans une seule.Multi-tenant application - A multi-tenant application is intended for use in many organizations, not just one organization. Il s’agit généralement d’applications SaaS (software-as-a-service) écrites par un éditeur de logiciels indépendant.These are typically software-as-a-service (SaaS) applications written by an independent software vendor (ISV). Les applications mutualisées doivent être approvisionnées dans chaque annuaire dans lequel elles sont utilisées, ce qui suppose le consentement d’un utilisateur ou d’un administrateur pour les inscrire.Multi-tenant applications need to be provisioned in each directory where they will be used, which requires user or administrator consent to register them. Ce processus de consentement démarre quand une application a été enregistrée dans l’annuaire et accède à l’API Graph ou à une autre API web.This consent process starts when an application has been registered in the directory and is given access to the Graph API or perhaps another web API. Lorsqu’un utilisateur ou un administrateur d’une autre organisation s’inscrit pour utiliser l’application, une boîte de dialogue contenant les autorisations que l’application requiert s’affiche.When a user or administrator from a different organization signs up to use the application, they are presented with a dialog that displays the permissions the application requires. L’utilisateur ou l’administrateur peut alors donner son consentement à l’application, ce qui permet à cette dernière d’accéder aux données indiquées et inscrit l’application dans l’annuaire de l’utilisateur ou de l’administrateur.The user or administrator can then consent to the application, which gives the application access to the stated data, and finally registers the application in their directory. Pour plus d’informations, consultez la page Vue d’ensemble de l’infrastructure de consentement.For more information, see Overview of the Consent Framework.

Considérations supplémentaires lors du développement d’applications à client unique ou à plusieurs clientsAdditional considerations when developing single tenant or multi-tenant apps

Vous devez tenir compte d’autres éléments lorsque vous choisissez de développer une application mutualisée plutôt qu’une application à client unique.Some additional considerations arise when developing a multi-tenant application instead of a single tenant application. Par exemple, si vous mettez votre application à la disposition des utilisateurs dans plusieurs annuaires, vous devez disposer d’un mécanisme permettant de déterminer dans quel client ils se trouvent.For example, if you are making your application available to users in multiple directories, you need a mechanism to determine which tenant they’re in. Il suffit à une application à client unique de rechercher l’utilisateur dans son propre annuaire, alors qu’une application mutualisée doit tenir compte de tous les annuaires d’Azure AD pour identifier un utilisateur particulier.A single tenant application only needs to look in its own directory for a user, while a multi-tenant application needs to identify a specific user from all the directories in Azure AD. À cet effet, Azure AD fournit un point de terminaison d’authentification commun vers lequel une application mutualisée peut diriger les demandes de connexion, plutôt que vers un point de terminaison spécifique au client.To accomplish this task, Azure AD provides a common authentication endpoint where any multi-tenant application can direct sign-in requests, instead of a tenant-specific endpoint. Ce point de terminaison est https://login.microsoftonline.com/common pour tous les annuaires dans Azure AD, tandis qu’un point de terminaison spécifique d’un client peut être https://login.microsoftonline.com/contoso.onmicrosoft.com.This endpoint is https://login.microsoftonline.com/common for all directories in Azure AD, whereas a tenant-specific endpoint might be https://login.microsoftonline.com/contoso.onmicrosoft.com. Lorsque vous développez votre application, il est particulièrement important de tenir compte du point de terminaison commun, car vous aurez besoin de la logique nécessaire à la gestion de plusieurs clients lors de la connexion, de la déconnexion et de la validation des jetons.The common endpoint is especially important to consider when developing your application because you’ll need the necessary logic to handle multiple tenants during sign-in, sign-out, and token validation.

Si vous développez actuellement une application à client unique, mais que vous souhaitez la mettre à disposition de plusieurs organisations, vous pouvez facilement apporter des modifications à l’application et à sa configuration dans Azure AD pour la rendre compatible avec la mutualisation.If you are currently developing a single tenant application but want to make it available to many organizations, you can easily make changes to the application and its configuration in Azure AD to make it multi-tenant capable. De plus, Azure AD utilise la même clé de signature pour tous les jetons de tous les annuaires, que vous fournissiez l’authentification dans une application à client unique ou mutualisée.In addition, Azure AD uses the same signing key for all tokens in all directories, whether you are providing authentication in a single tenant or multi-tenant application.

Chaque scénario répertorié dans ce document inclut une sous-section décrivant les exigences d’approvisionnement associées.Each scenario listed in this document includes a subsection that describes its provisioning requirements. Pour obtenir des informations plus détaillées sur l’approvisionnement d’une application dans Azure AD et sur les différences entre les applications à client unique et les applications mutualisées, consultez Intégration d’applications dans Azure Active Directory.For more in-depth information about provisioning an application in Azure AD and the differences between single and multi-tenant applications, see Integrating applications with Azure Active Directory for more information. Poursuivez votre lecture pour comprendre les scénarios d’application courants dans Azure AD.Continue reading to understand the common application scenarios in Azure AD.

Types d’application et scénariosApplication Types and Scenarios

Chacun des scénarios décrits ici peut être développé à l’aide de différents langages et plateformes.Each of the scenarios described here can be developed using various languages and platforms. Tous s’appuient sur des exemples de code complets disponibles dans le guide d’exemples de code, ou directement à partir des dépôts d’exemples GitHub correspondants.They are all backed by complete code samples available in the Code Samples guide, or directly from the corresponding GitHub sample repositories. De plus, si votre application nécessite un élément ou segment spécifique d’un scénario de bout en bout, vous pouvez ajouter cette fonctionnalité séparément dans la plupart des cas.In addition, if your application needs a specific piece or segment of an end-to-end scenario, in most cases that functionality can be added independently. Par exemple, si vous avez une application native qui appelle une API web, vous pouvez facilement ajouter une application web qui appelle elle-aussi l’API web.For example, if you have a native application that calls a web API, you can easily add a web application that also calls the web API. Le diagramme suivant illustre ces scénarios et types d’application, ainsi que la manière dont vous pouvez ajouter les différents composants :The following diagram illustrates these scenarios and application types, and how different components can be added:

Types d’application et scénarios

Voici les cinq principaux scénarios d’application pris en charge par Azure AD :These are the five primary application scenarios supported by Azure AD:

Navigateur web vers application webWeb browser to web application

Cette section décrit une application authentifiant un utilisateur d’un navigateur web auprès d’une application web.This section describes an application that authenticates a user in a web browser to a web application. Dans ce scénario, l’application web dirige le navigateur de l’utilisateur pour connecter ce dernier à Azure AD.In this scenario, the web application directs the user’s browser to sign them in to Azure AD. Azure AD renvoie une réponse de connexion via le navigateur de l’utilisateur, celle-ci contenant des revendications relatives à l’utilisateur dans un jeton de sécurité.Azure AD returns a sign-in response through the user’s browser, which contains claims about the user in a security token. Ce scénario prend en charge l’authentification à l’aide des protocoles WS-Federation, SAML 2.0 et OpenID Connect.This scenario supports sign-on using the WS-Federation, SAML 2.0, and OpenID Connect protocols.

DiagrammeDiagram

Flux d’authentification pour le scénario du type navigateur vers application web

Description du flux du protocoleDescription of protocol flow

  1. Quand un utilisateur accède à l’application et doit se connecter, il est redirigé via une demande de connexion au point de terminaison d’authentification d’Azure AD.When a user visits the application and needs to sign in, they are redirected via a sign-in request to the authentication endpoint in Azure AD.
  2. L’utilisateur se connecte sur la page de connexion.The user signs in on the sign-in page.
  3. Si l’authentification réussit, Azure AD crée un jeton d’authentification et renvoie une réponse de connexion à l’URL de réponse de l’application qui a été configurée dans le portail Azure.If authentication is successful, Azure AD creates an authentication token and returns a sign-in response to the application’s Reply URL that was configured in the Azure portal. Pour une application de production, cette URL de réponse doit être au format HTTPS.For a production application, this Reply URL should be HTTPS. Le jeton renvoyé inclut des revendications sur l’utilisateur et Azure AD dont l’application a besoin pour valider le jeton.The returned token includes claims about the user and Azure AD that are required by the application to validate the token.
  4. L’application valide le jeton à l’aide d’une clé de signature publique et des informations sur l’émetteur disponibles dans le document de métadonnées de fédération pour Azure AD.The application validates the token by using a public signing key and issuer information available at the federation metadata document for Azure AD. Une fois que l’application a validé le jeton, elle démarre une nouvelle session avec l’utilisateur.After the application validates the token, it starts a new session with the user. Cette session permet à l’utilisateur d’accéder à l’application jusqu’à expiration de la session.This session allows the user to access the application until it expires.

Exemples de codeCode samples

Consultez les exemples de code pour les scénarios du type navigateur web vers application web.See the code samples for Web Browser to Web Application scenarios. Et consultez régulièrement cette page à laquelle nous ajoutons fréquemment de nouveaux exemples.And, check back frequently -- new samples are added frequently. Application webWeb Application.

InscriptionRegistering

  • Application à client unique : si vous créez une application uniquement pour votre organisation, vous devez l’inscrire dans l’annuaire de votre entreprise à l’aide du portail Azure.Single Tenant: If you are building an application just for your organization, it must be registered in your company’s directory by using the Azure portal.
  • Application mutualisée : si vous créez une application qui peut être utilisée par des utilisateurs externes, vous devez l’inscrire dans l’annuaire de votre entreprise, mais également dans celui de chaque organisation qui utilisera l’application.Multi-Tenant: If you are building an application that can be used by users outside your organization, it must be registered in your company’s directory, but also must be registered in each organization’s directory that will be using the application. Afin de mettre votre application à disposition dans ces annuaires, vous pouvez inclure pour vos clients un processus d’inscription qui leur permet de donner leur consentement à votre application.To make your application available in their directory, you can include a sign-up process for your customers that enables them to consent to your application. Quand ils s’inscrivent auprès de votre application, une boîte de dialogue contenant les autorisations requises par l’application s’affiche, et ils ont ensuite la possibilité de donner leur consentement.When they sign up for your application, they will be presented with a dialog that shows the permissions the application requires, and then the option to consent. Selon les autorisations requises, il est possible qu’un administrateur de l’autre organisation doive donner le consentement.Depending on the required permissions, an administrator in the other organization may be required to give consent. Une fois le consentement donné par l’utilisateur ou l’administrateur, l’application est inscrite dans l’annuaire de l’organisation de l’utilisateur ou de l’administrateur.When the user or administrator consents, the application is registered in their directory. Pour plus d’informations, consultez Intégration d’applications dans Azure Active Directory.For more information, see Integrating Applications with Azure Active Directory.

Expiration du jetonToken expiration

La session utilisateur expire lorsque la durée de vie du jeton émis par Azure AD arrive à expiration.The user’s session expires when the lifetime of the token issued by Azure AD expires. Votre application peut raccourcir cette durée au besoin, par exemple en déconnectant les utilisateurs suite à une période d’inactivité.Your application can shorten this time period if desired, such as signing out users based on a period of inactivity. Lorsque la session arrive à expiration, l’utilisateur est invité à se connecter à nouveau.When the session expires, the user will be prompted to sign in again.

Application à page unique (SPA)Single Page Application (SPA)

Cette section décrit l’authentification pour une application à page unique utilisant Azure AD et l’octroi d’autorisation implicite OAuth 2.0 afin de sécuriser les composants principaux de son API web.This section describes authentication for a Single Page Application, that uses Azure AD and the OAuth 2.0 implicit authorization grant to secure its web API back end. Les applications à page unique sont généralement structurées comme une couche présentation (frontale) JavaScript qui s’exécute dans le navigateur et comme les composants principaux d’une API web qui s’exécute sur un serveur et implémente la logique métier de l’application.Single Page Applications are typically structured as a JavaScript presentation layer (front end) that runs in the browser and a Web API back end that runs on a server and implements the application’s business logic. Pour plus d’informations sur l’octroi d’autorisation implicite et pour vous aider à décider si cette méthode est adaptée à votre scénario d’application, consultez Comprendre le flux d’octroi implicite OAuth2 dans Azure Active Directory (AD).To learn more about the implicit authorization grant, and help you decide whether it's right for your application scenario, see Understanding the OAuth2 implicit grant flow in Azure Active Directory.

Dans ce scénario, quand l’utilisateur se connecte, le JavaScript frontal utilise Active Directory Authentication Library pour JavaScript (ADAL.JS) et l’octroi d’autorisation implicite pour obtenir un jeton d’ID (id_token) d’Azure AD.In this scenario, when the user signs in, the JavaScript front end uses Active Directory Authentication Library for JavaScript (ADAL.JS) and the implicit authorization grant to obtain an ID token (id_token) from Azure AD. Le jeton est mis en cache, et le client l’attache à la demande en tant que jeton porteur lors de l’appel des composants principaux de son API web, qui sont sécurisés à l’aide de l’intergiciel OWIN.The token is cached and the client attaches it to the request as the bearer token when making calls to its Web API back end, which is secured using the OWIN middleware.

DiagrammeDiagram

Diagramme Application à page unique (SPA)

Description du flux du protocoleDescription of protocol flow

  1. L’utilisateur accède à l’application web.The user navigates to the web application.
  2. L’application renvoie le JavaScript frontal (couche présentation) au navigateur.The application returns the JavaScript front end (presentation layer) to the browser.
  3. L’utilisateur établit la connexion, par exemple en cliquant sur un lien de connexion.The user initiates sign in, for example by clicking a sign-in link. Le navigateur envoie une commande GET au point de terminaison d’autorisation Azure AD pour demander un jeton d’ID.The browser sends a GET to the Azure AD authorization endpoint to request an ID token. Les paramètres de requête de cette demande comprennent l’ID d’application et l’URL de réponse.This request includes the application ID and reply URL in the query parameters.
  4. Azure AD valide l’URL de réponse par rapport à celle enregistrée et configurée dans le portail Azure.Azure AD validates the Reply URL against the registered Reply URL that was configured in the Azure portal.
  5. L’utilisateur se connecte sur la page de connexion.The user signs in on the sign-in page.
  6. Si l’authentification réussit, Azure AD crée un jeton d’ID et le renvoie à l’URL de réponse de l’application sous forme de fragment d’URL (#).If authentication is successful, Azure AD creates an ID token and returns it as a URL fragment (#) to the application’s Reply URL. Pour une application de production, cette URL de réponse doit être au format HTTPS.For a production application, this Reply URL should be HTTPS. Le jeton renvoyé inclut des revendications sur l’utilisateur et Azure AD dont l’application a besoin pour valider le jeton.The returned token includes claims about the user and Azure AD that are required by the application to validate the token.
  7. Le code client JavaScript exécuté dans le navigateur extrait le jeton de la réponse afin de l’utiliser pour la sécurisation des appels vers les composants principaux de l’API web de l’application.The JavaScript client code running in the browser extracts the token from the response to use in securing calls to the application’s web API back end.
  8. Le navigateur appelle les composants principaux de l’API web de l’application, avec le jeton d’accès dans l’en-tête d’autorisation.The browser calls the application’s web API back end with the access token in the authorization header.

Exemples de codeCode samples

Consultez les exemples de code pour les scénarios du type application à page unique (SPA).See the code samples for Single Page Application (SPA) scenarios. Veillez à consultez régulièrement cette page à laquelle nous ajoutons fréquemment de nouveaux exemples.Be sure to check back frequently -- new samples are added frequently. Application à page unique (SPA).Single Page Application (SPA).

InscriptionRegistering

  • Application à client unique : si vous créez une application uniquement pour votre organisation, vous devez l’inscrire dans l’annuaire de votre entreprise à l’aide du portail Azure.Single Tenant: If you are building an application just for your organization, it must be registered in your company’s directory by using the Azure portal.
  • Application mutualisée : si vous créez une application qui peut être utilisée par des utilisateurs externes, vous devez l’inscrire dans l’annuaire de votre entreprise, mais également dans celui de chaque organisation qui utilisera l’application.Multi-Tenant: If you are building an application that can be used by users outside your organization, it must be registered in your company’s directory, but also must be registered in each organization’s directory that will be using the application. Afin de mettre votre application à disposition dans ces annuaires, vous pouvez inclure pour vos clients un processus d’inscription qui leur permet de donner leur consentement à votre application.To make your application available in their directory, you can include a sign-up process for your customers that enables them to consent to your application. Quand ils s’inscrivent auprès de votre application, une boîte de dialogue contenant les autorisations requises par l’application s’affiche, et ils ont ensuite la possibilité de donner leur consentement.When they sign up for your application, they will be presented with a dialog that shows the permissions the application requires, and then the option to consent. Selon les autorisations requises, il est possible qu’un administrateur de l’autre organisation doive donner le consentement.Depending on the required permissions, an administrator in the other organization may be required to give consent. Une fois le consentement donné par l’utilisateur ou l’administrateur, l’application est inscrite dans l’annuaire de l’organisation de l’utilisateur ou de l’administrateur.When the user or administrator consents, the application is registered in their directory. Pour plus d’informations, consultez Intégration d’applications dans Azure Active Directory.For more information, see Integrating Applications with Azure Active Directory.

Après avoir inscrit l’application, vous devez la configurer pour qu’elle utilise le protocole d’octroi implicite OAuth 2.0.After registering the application, it must be configured to use OAuth 2.0 Implicit Grant protocol. Par défaut, ce protocole est désactivé pour les applications.By default, this protocol is disabled for applications. Pour activer le protocole d’octroi implicite OAuth2 pour votre application, modifiez son manifeste d’application à partir du portail Azure et définissez la valeur « oauth2AllowImplicitFlow » sur True.To enable the OAuth2 Implicit Grant protocol for your application, edit its application manifest from the Azure portal and set the “oauth2AllowImplicitFlow” value to true. Pour obtenir des instructions détaillées, consultez la rubrique Activation de l’octroi implicite OAuth 2.0 pour les applications à page unique.For detailed instructions, see Enabling OAuth 2.0 Implicit Grant for Single Page Applications.

Expiration du jetonToken expiration

L’utilisation d’ADAL.js est utile pour ce qui suit :Using ADAL.js helps with:

  • actualiser un jeton expiré ;refreshing an expired token
  • demander un jeton d’accès pour appeler une ressource d’API web.requesting an access token to call a web API resource

Après une authentification réussie, Azure AD écrit un cookie dans le navigateur de l’utilisateur pour établir une session.After a successful authentication, Azure AD writes a cookie in the user's browser to establish a session. Notez que la session existe entre l’utilisateur et Azure AD (pas entre l’utilisateur et l’application web).Note the session exists between the user and Azure AD (not between the user and the web application). Lorsqu’un jeton arrive à expiration, ADAL.js utilise cette session pour obtenir un autre jeton en mode silencieux.When a token expires, ADAL.js uses this session to silently obtain another token. ADAL.js utilise un iFrame masqué pour l’envoi et la réception de la demande à l’aide du protocole d’octroi implicite OAuth.ADAL.js uses a hidden iFrame to send and receive the request using the OAuth Implicit Grant protocol. ADAL.js peut également utiliser ce mécanisme afin d’obtenir des jetons d’accès en mode silencieux pour d’autres ressources d’API web que l’application appelle, à condition que ces ressources prennent en charge le partage des ressources cross-origin (CORS) et soient inscrites dans l’annuaire de l’utilisateur, et que l’utilisateur ait donné le consentement requis au moment de la connexion.ADAL.js can also use this same mechanism to silently obtain access tokens for other web API resources the application calls as long as these resources support cross-origin resource sharing (CORS), are registered in the user’s directory, and any required consent was given by the user during sign-in.

Application native vers API webNative application to web API

Cette section décrit l’appel d’une API web par une application native au nom d’un utilisateur.This section describes a native application that calls a web API on behalf of a user. Ce scénario repose sur le type d’octroi de code d’autorisation OAuth 2.0 avec un client public, comme décrit à la section 4.1 de la spécification OAuth 2.0.This scenario is built on the OAuth 2.0 authorization code grant type with a public client, as described in section 4.1 of the OAuth 2.0 specification. L’application native obtient un jeton d’accès pour l’utilisateur à l’aide du protocole OAuth 2.0.The native application obtains an access token for the user by using the OAuth 2.0 protocol. Ce jeton d’accès est ensuite envoyé via la demande à l’API web, qui autorise l’utilisateur et renvoie la ressource souhaitée.This access token is then sent in the request to the web API, which authorizes the user and returns the desired resource.

DiagrammeDiagram

Diagramme Application native vers API web

Description du flux du protocoleDescription of protocol flow

Si vous utilisez les bibliothèques d’authentification AD, la plupart des détails de protocole décrits ci-dessous sont gérés pour vous, notamment les fenêtres contextuelles du navigateur, la mise en cache des jetons et la gestion des jetons d’actualisation.If you are using the AD Authentication Libraries, most of the protocol details described below are handled for you, such as the browser pop-up, token caching, and handling of refresh tokens.

  1. À l’aide d’une fenêtre contextuelle du navigateur, l’application native envoie une demande au point de terminaison d’autorisation d’Azure AD.Using a browser pop-up, the native application makes a request to the authorization endpoint in Azure AD. Cette demande comprend l’ID d’application et l’URI de redirection de l’application native tels qu’ils figurent dans le portail Azure, et l’URI d’ID d’application de l’API web.This request includes the Application ID and the redirect URI of the native application as shown in the Azure portal, and the application ID URI for the web API. Si l’utilisateur ne s’est pas déjà connecté, il est invité à nouveau à se connecter.If the user hasn’t already signed in, they are prompted to sign in again
  2. Azure AD authentifie l’utilisateur.Azure AD authenticates the user. S’il s’agit d’une application mutualisée et si un consentement est requis pour utiliser l’application, l’utilisateur doit donner son consentement, s’il ne l’a pas déjà fait.If it is a multi-tenant application and consent is required to use the application, the user will be required to consent if they haven’t already done so. Une fois le consentement donné et l’authentification réussie, Azure AD renvoie une réponse de code d’autorisation à l’URI de redirection de l’application cliente.After granting consent and upon successful authentication, Azure AD issues an authorization code response back to the client application’s redirect URI.
  3. Quand Azure AD renvoie une réponse de code d’autorisation à l’URI de redirection, l’application cliente arrête l’interaction du navigateur et extrait le code d’autorisation de la réponse.When Azure AD issues an authorization code response back to the redirect URI, the client application stops browser interaction and extracts the authorization code from the response. À l’aide de ce code d’autorisation, l’application cliente envoie une demande au point de terminaison de jeton d’Azure AD. Celle-ci comprend le code d’autorisation, des détails sur l’application cliente (ID d’application et URI de redirection) et la ressource souhaitée (URI ID d’application de l’API web).Using this authorization code, the client application sends a request to Azure AD’s token endpoint that includes the authorization code, details about the client application (Application ID and redirect URI), and the desired resource (application ID URI for the web API).
  4. Le code d’autorisation et les informations sur l’application cliente et l’API web sont validés par Azure AD.The authorization code and information about the client application and web API are validated by Azure AD. Si la validation réussit, Azure AD renvoie deux jetons : un jeton d’accès JWT et un jeton d’actualisation JWT.Upon successful validation, Azure AD returns two tokens: a JWT access token and a JWT refresh token. Azure AD renvoie également des informations de base sur l’utilisateur, telles que son nom d’affichage et son ID client.In addition, Azure AD returns basic information about the user, such as their display name and tenant ID.
  5. Sur HTTPS, l’application cliente utilise le jeton d’accès JWT renvoyé pour ajouter la chaîne JWT avec la mention « porteur » dans l’en-tête d’autorisation de la demande adressée à l’API web.Over HTTPS, the client application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L’API web valide ensuite le jeton JWT et, si la validation réussit, renvoie la ressource souhaitée.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
  6. Quand le jeton d’accès arrive à expiration, l’application cliente reçoit une erreur indiquant que l’utilisateur doit s’authentifier à nouveau.When the access token expires, the client application will receive an error that indicates the user needs to authenticate again. Si l’application dispose d’un jeton d’actualisation valide, celui-ci peut être utilisé pour obtenir un nouveau jeton d’accès sans demander à l’utilisateur de se connecter à nouveau.If the application has a valid refresh token, it can be used to acquire a new access token without prompting the user to sign in again. Si le jeton d’actualisation arrive à expiration, l’application doit interactivement authentifier l’utilisateur une nouvelle fois.If the refresh token expires, the application will need to interactively authenticate the user once again.

Note

Le jeton d’actualisation émis par Azure AD peut être utilisé pour accéder à plusieurs ressources.The refresh token issued by Azure AD can be used to access multiple resources. Par exemple, si une application cliente est autorisée à appeler deux API web, le jeton d’actualisation peut être utilisé pour obtenir un jeton d’accès à l’autre API web également.For example, if you have a client application that has permission to call two web APIs, the refresh token can be used to get an access token to the other web API as well.

Exemples de codeCode samples

Consultez les exemples de code pour les scénarios du type application native vers API web.See the code samples for Native Application to Web API scenarios. Et consultez régulièrement cette page à laquelle nous ajoutons fréquemment de nouveaux exemples.And, check back frequently -- we add new samples frequently. Application native vers API web.Native Application to Web API.

InscriptionRegistering

  • Application à client unique : l’application native et l’API web doivent être inscrites dans le même annuaire dans Azure AD.Single Tenant: Both the native application and the web API must be registered in the same directory in Azure AD. L’API web peut être configurée pour exposer un ensemble d’autorisations utilisées pour limiter l’accès de l’application native à ses ressources.The web API can be configured to expose a set of permissions, which are used to limit the native application’s access to its resources. L’application cliente sélectionne ensuite les autorisations souhaitées dans le menu déroulant « Autorisations pour d’autres applications » du portail Azure.The client application then selects the desired permissions from the “Permissions to Other Applications” drop-down menu in the Azure portal.
  • Application mutualisée : premièrement, l’application native est toujours inscrite dans l’annuaire du développeur ou de l’éditeur.Multi-Tenant: First, the native application only ever registered in the developer or publisher’s directory. Deuxièmement, l’application native est configurée pour indiquer les autorisations dont elle a besoin pour fonctionner.Second, the native application is configured to indicate the permissions it requires to be functional. Cette liste d’autorisations requises s’affiche dans une boîte de dialogue quand un utilisateur ou un administrateur de l’annuaire de destination donne son consentement à l’application, ce qui la met à disposition de son organisation.This list of required permissions is shown in a dialog when a user or administrator in the destination directory gives consent to the application, which makes it available to their organization. Certaines applications nécessitent uniquement des autorisations au niveau utilisateur pour lesquelles tous les utilisateurs de l’organisation peuvent donner leur consentement.Some applications only require user-level permissions, which any user in the organization can consent to. D’autres nécessitent des autorisations administrateur, pour lesquelles un utilisateur de l’organisation ne peut pas donner son consentement.Other applications require administrator-level permissions, which a user in the organization cannot consent to. Seul un administrateur d’annuaires peut donner son consentement aux applications qui requièrent des autorisations de ce niveau.Only a directory administrator can give consent to applications that require this level of permissions. Quand un utilisateur ou un administrateur donne son consentement, seule l’API web est inscrite dans son annuaire.When the user or administrator consents, only the web API is registered in their directory. Pour plus d’informations, consultez Intégration d’applications dans Azure Active Directory.For more information, see Integrating Applications with Azure Active Directory.

Expiration du jetonToken expiration

Quand l’application native utilise son code d’autorisation pour obtenir un jeton d’accès JWT, elle reçoit également un jeton d’actualisation JWT.When the native application uses its authorization code to get a JWT access token, it also receives a JWT refresh token. À l’expiration du jeton d’accès, le jeton d’actualisation peut être utilisé pour authentifier l’utilisateur à nouveau sans lui demander de se connecter une nouvelle fois.When the access token expires, the refresh token can be used to re-authenticate the user without requiring them to sign in again. Ce jeton d’actualisation est ensuite utilisé pour authentifier l’utilisateur, ce qui donne lieu à la création d’un nouveau jeton d’accès et d’un nouveau jeton d’actualisation.This refresh token is then used to authenticate the user, which results in a new access token and refresh token.

Application web vers API webWeb application to web API

Cette section décrit une application web ayant besoin d’obtenir des ressources d’une API web.This section describes a web application that needs to get resources from a web API. Dans ce scénario, il existe deux types d’identité que l’application web peut utiliser pour authentifier et appeler l’API web : une identité d’application ou une identité d’utilisateur délégué.In this scenario, there are two identity types that the web application can use to authenticate and call the web API: an application identity, or a delegated user identity.

Identité d’application : ce scénario utilise l’octroi d’informations d’identification client OAuth 2.0 pour l’authentification en tant qu’application et l’accès à l’API web.Application identity: This scenario uses OAuth 2.0 client credentials grant to authenticate as the application and access the web API. Avec une identité d’application, l’API web peut détecter uniquement que l’application web l’appelle, car elle ne reçoit aucune information sur l’utilisateur.When using an application identity, the web API can only detect that the web application is calling it, as the web API does not receive any information about the user. Si l’application reçoit des informations sur l’utilisateur, celles-ci sont envoyées via le protocole d’application et ne sont pas signées par Azure AD.If the application receives information about the user, it will be sent via the application protocol, and it is not signed by Azure AD. L’API web suppose que l’application web a authentifié l’utilisateur.The web API trusts that the web application authenticated the user. C’est pour cette raison que ce modèle est appelé « sous-système approuvé ».For this reason, this pattern is called a trusted subsystem.

Identité d’utilisateur délégué : ce scénario peut être obtenu de deux façons : OpenID Connect et octroi de code d’autorisation OAuth 2.0 avec un client confidentiel.Delegated user identity: This scenario can be accomplished in two ways: OpenID Connect, and OAuth 2.0 authorization code grant with a confidential client. L’application web obtient un jeton d’accès pour l’utilisateur, ce qui prouve à l’API web que l’utilisateur s’est correctement authentifié auprès de l’application web et que l’application web a pu obtenir une identité d’utilisateur délégué pour appeler l’API web.The web application obtains an access token for the user, which proves to the web API that the user successfully authenticated to the web application and that the web application was able to obtain a delegated user identity to call the web API. Ce jeton d’accès est envoyé via la demande à l’API web, qui autorise l’utilisateur et renvoie la ressource souhaitée.This access token is sent in the request to the web API, which authorizes the user and returns the desired resource.

DiagrammeDiagram

Diagramme Application web vers API web

Description du flux du protocoleDescription of protocol flow

L’identité d’application et l’identité d’utilisateur délégué sont décrites dans le flux ci-après.Both the application identity and delegated user identity types are discussed in the flow below. La différence principale entre ces deux types d’identité est que l’identité d’utilisateur délégué doit obtenir un code d’autorisation avant que l’utilisateur puisse se connecter et accéder à l’API web.The key difference between them is that the delegated user identity must first acquire an authorization code before the user can sign in and gain access to the web API.

Identité d’application avec octroi d’informations d’identification client OAuth 2.0Application identity with OAuth 2.0 client credentials grant
  1. Un utilisateur est connecté à Azure AD dans l’application web (voir la section Navigateur web vers application web ci-dessus).A user is signed in to Azure AD in the web application (see the Web Browser to Web Application above).
  2. L’application web doit obtenir un jeton d’accès pour pouvoir s’authentifier auprès de l’API web et extraire la ressource souhaitée.The web application needs to acquire an access token so that it can authenticate to the web API and retrieve the desired resource. Elle envoie une demande au point de terminaison de jeton d’Azure AD, avec les informations d’identification, l’ID d’application et l’URI ID d’application de l’API web.It makes a request to Azure AD’s token endpoint, providing the credential, Application ID, and web API’s application ID URI.
  3. Azure AD authentifie l’application et renvoie un jeton d’accès JWT, qui est utilisé pour appeler l’API web.Azure AD authenticates the application and returns a JWT access token that is used to call the web API.
  4. Sur HTTPS, l’application web utilise le jeton d’accès JWT renvoyé pour ajouter la chaîne JWT avec la mention « porteur » dans l’en-tête d’autorisation de la demande adressée à l’API web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L’API web valide ensuite le jeton JWT et, si la validation réussit, renvoie la ressource souhaitée.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
Identité d’utilisateur délégué avec OpenID ConnectDelegated user identity with OpenID Connect
  1. Un utilisateur est connecté à une application web via Azure AD (voir la section Navigateur web vers application web ci-dessus).A user is signed in to a web application using Azure AD (see the Web Browser to Web Application section above). Si l’utilisateur de l’application web n’a pas encore consenti à autoriser l’application web à appeler l’API web en son nom, il doit donner son consentement.If the user of the web application has not yet consented to allowing the web application to call the web API on its behalf, the user will need to consent. L’application affiche les autorisations nécessaires et, si certaines d’entre elles sont des autorisations administrateur, un utilisateur normal de l’annuaire ne peut pas donner le consentement.The application will display the permissions it requires, and if any of these are administrator-level permissions, a normal user in the directory will not be able to consent. Ce processus de consentement s’applique uniquement aux applications mutualisées, pas aux applications à client unique, car l’application a déjà les autorisations nécessaires.This consent process only applies to multi-tenant applications, not single tenant applications, as the application will already have the necessary permissions. Quand l’utilisateur s’est connecté, l’application web a reçu un jeton d’ID avec les informations sur l’utilisateur, ainsi qu’un code d’autorisation.When the user signed in, the web application received an ID token with information about the user, as well as an authorization code.
  2. À l’aide du code d’autorisation émis par Azure AD, l’application web envoie une demande au point de terminaison de jeton d’Azure AD. Celle-ci comprend le code d’autorisation, des détails sur l’application cliente (ID d’application et URI de redirection) et la ressource souhaitée (URI ID d’application de l’API web).Using the authorization code issued by Azure AD, the web application sends a request to Azure AD’s token endpoint that includes the authorization code, details about the client application (Application ID and redirect URI), and the desired resource (application ID URI for the web API).
  3. Le code d’autorisation et les informations sur l’application web et l’API web sont validés par Azure AD.The authorization code and information about the web application and web API are validated by Azure AD. Si la validation réussit, Azure AD renvoie deux jetons : un jeton d’accès JWT et un jeton d’actualisation JWT.Upon successful validation, Azure AD returns two tokens: a JWT access token and a JWT refresh token.
  4. Sur HTTPS, l’application web utilise le jeton d’accès JWT renvoyé pour ajouter la chaîne JWT avec la mention « porteur » dans l’en-tête d’autorisation de la demande adressée à l’API web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L’API web valide ensuite le jeton JWT et, si la validation réussit, renvoie la ressource souhaitée.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
Identité d’utilisateur délégué avec octroi de code d’autorisation OAuth 2.0Delegated user identity with OAuth 2.0 authorization code grant
  1. Un utilisateur est déjà connecté à une application web, dont le mécanisme d’authentification est indépendant d’Azure AD.A user is already signed in to a web application, whose authentication mechanism is independent of Azure AD.
  2. L’application web a besoin d’un code d’autorisation pour obtenir un jeton d’accès et adresse donc une demande au point de terminaison d’autorisation d’Azure AD via le navigateur, en indiquant l’ID d’application et l’URI de redirection de l’application web une fois l’authentification réussie.The web application requires an authorization code to acquire an access token, so it issues a request through the browser to Azure AD’s authorization endpoint, providing the Application ID and redirect URI for the web application after successful authentication. L’utilisateur se connecte à Azure AD.The user signs in to Azure AD.
  3. Si l’utilisateur de l’application web n’a pas encore consenti à autoriser l’application web à appeler l’API web en son nom, il doit donner son consentement.If the user of the web application has not yet consented to allowing the web application to call the web API on its behalf, the user will need to consent. L’application affiche les autorisations nécessaires et, si certaines d’entre elles sont des autorisations administrateur, un utilisateur normal de l’annuaire ne peut pas donner le consentement.The application will display the permissions it requires, and if any of these are administrator-level permissions, a normal user in the directory will not be able to consent. Ce consentement s’applique à l’application unique et multi-locataire.This consent applies to both single and multi-tenant application. Dans le cas d’un client unique, un administrateur peut effectuer le consentement d’administrateur pour consentir pour le compte de leurs utilisateurs.In the single tenant case, an admin can perform admin consent to consent on behalf of their users. Cela est possible à l’aide du bouton Grant Permissions situé dans le Portail Azure.This can be done using the Grant Permissions button in the Azure Portal.
  4. Une fois que l’utilisateur a donné son consentement, l’application web reçoit le code d’autorisation dont elle a besoin pour obtenir un jeton d’accès.After the user has consented, the web application receives the authorization code that it needs to acquire an access token.
  5. À l’aide du code d’autorisation émis par Azure AD, l’application web envoie une demande au point de terminaison de jeton d’Azure AD. Celle-ci comprend le code d’autorisation, des détails sur l’application cliente (ID d’application et URI de redirection) et la ressource souhaitée (URI ID d’application de l’API web).Using the authorization code issued by Azure AD, the web application sends a request to Azure AD’s token endpoint that includes the authorization code, details about the client application (Application ID and redirect URI), and the desired resource (application ID URI for the web API).
  6. Le code d’autorisation et les informations sur l’application web et l’API web sont validés par Azure AD.The authorization code and information about the web application and web API are validated by Azure AD. Si la validation réussit, Azure AD renvoie deux jetons : un jeton d’accès JWT et un jeton d’actualisation JWT.Upon successful validation, Azure AD returns two tokens: a JWT access token and a JWT refresh token.
  7. Sur HTTPS, l’application web utilise le jeton d’accès JWT renvoyé pour ajouter la chaîne JWT avec la mention « porteur » dans l’en-tête d’autorisation de la demande adressée à l’API web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L’API web valide ensuite le jeton JWT et, si la validation réussit, renvoie la ressource souhaitée.The web API then validates the JWT token, and if validation is successful, returns the desired resource.

Exemples de codeCode samples

Consultez les exemples de code pour les scénarios du type application web vers API web.See the code samples for Web Application to Web API scenarios. Et consultez régulièrement cette page à laquelle nous ajoutons fréquemment de nouveaux exemples.And, check back frequently -- new samples are added frequently. Application web vers API web.Web Application to Web API.

InscriptionRegistering

  • Application à client unique : pour les identités d’application et les identités d’utilisateur délégué, l’application web et l’API web doivent être inscrites dans le même annuaire dans Azure AD.Single Tenant: For both the application identity and delegated user identity cases, the web application and the web API must be registered in the same directory in Azure AD. L’API web peut être configurée pour exposer un ensemble d’autorisations utilisées pour limiter l’accès de l’application web à ses ressources.The web API can be configured to expose a set of permissions, which are used to limit the web application’s access to its resources. Si une identité d’utilisateur délégué est utilisée, l’application web doit sélectionner les autorisations souhaitées dans le menu déroulant « Autorisations pour d’autres applications » du portail Azure.If a delegated user identity type is being used, the web application needs to select the desired permissions from the “Permissions to Other Applications” drop-down menu in the Azure portal. Cette étape n’est pas requise si une identité d’application est utilisée.This step is not required if the application identity type is being used.
  • Application mutualisée : tout d’abord, l’application web est configurée pour indiquer les autorisations dont elle a besoin pour fonctionner.Multi-Tenant: First, the web application is configured to indicate the permissions it requires to be functional. Cette liste d’autorisations requises s’affiche dans une boîte de dialogue quand un utilisateur ou un administrateur de l’annuaire de destination donne son consentement à l’application, ce qui la met à disposition de son organisation.This list of required permissions is shown in a dialog when a user or administrator in the destination directory gives consent to the application, which makes it available to their organization. Certaines applications nécessitent uniquement des autorisations au niveau utilisateur pour lesquelles tous les utilisateurs de l’organisation peuvent donner leur consentement.Some applications only require user-level permissions, which any user in the organization can consent to. D’autres nécessitent des autorisations administrateur, pour lesquelles un utilisateur de l’organisation ne peut pas donner son consentement.Other applications require administrator-level permissions, which a user in the organization cannot consent to. Seul un administrateur d’annuaires peut donner son consentement aux applications qui requièrent des autorisations de ce niveau.Only a directory administrator can give consent to applications that require this level of permissions. Une fois le consentement donné par l’utilisateur ou l’administrateur, l’application web et l’API web sont inscrites dans l’annuaire de l’organisation de l’utilisateur ou de l’administrateur.When the user or administrator consents, the web application and the web API are both registered in their directory.

Expiration du jetonToken expiration

Quand l’application web utilise son code d’autorisation pour obtenir un jeton d’accès JWT, elle reçoit également un jeton d’actualisation JWT.When the web application uses its authorization code to get a JWT access token, it also receives a JWT refresh token. À l’expiration du jeton d’accès , le jeton d’actualisation peut être utilisé pour authentifier l’utilisateur à nouveau sans lui demander de se connecter une nouvelle fois.When the access token expires, the refresh token can be used to re-authenticate the user without requiring them to sign in again. Ce jeton d’actualisation est ensuite utilisé pour authentifier l’utilisateur, ce qui donne lieu à la création d’un nouveau jeton d’accès et d’un nouveau jeton d’actualisation.This refresh token is then used to authenticate the user, which results in a new access token and refresh token.

Application démon ou serveur vers API webDaemon or server application to web API

Cette section décrit une application démon ou serveur ayant besoin d’obtenir des ressources d’une API web.This section describes a daemon or server application that needs to get resources from a web API. Deux scénarios secondaires s’appliquent à cette section : un démon doit appeler une API web, scénario basé sur l’octroi d’informations d’identification client OAuth 2.0 ; et une application serveur (par exemple, une API web) doit appeler une API web, scénario basé sur la spécification préliminaire « Au nom de » OAuth 2.0.There are two sub-scenarios that apply to this section: A daemon that needs to call a web API, built on OAuth 2.0 client credentials grant type; and a server application (such as a web API) that needs to call a web API, built on OAuth 2.0 On-Behalf-Of draft specification.

Pour le scénario dans lequel une application démon doit appeler une API web, il est important de comprendre un certain nombre de choses.For the scenario when a daemon application needs to call a web API, it’s important to understand a few things. Tout d’abord, l’intervention de l’utilisateur n’est pas possible avec une application démon, qui requiert que l’application ait sa propre identité.First, user interaction is not possible with a daemon application, which requires the application to have its own identity. Le traitement par lots et un service de système d’exploitation exécuté en arrière-plan sont des exemples d’application démon.An example of a daemon application is a batch job, or an operating system service running in the background. Ce type d’application demande un jeton d’accès en utilisant son identité d’application et en fournissant à Azure AD son ID d’application, ses informations d’identification (mot de passe ou certificat) et l’URI ID d’application.This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. Une fois l’authentification réussie, le démon reçoit un jeton d’accès d’Azure AD. Celui-ci est ensuite utilisé pour appeler l’API web.After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.

Pour le scénario dans lequel une application serveur doit appeler une API web, nous allons prendre un exemple afin de faciliter la compréhension.For the scenario when a server application needs to call a web API, it’s helpful to use an example. Imaginez qu’un utilisateur se soit authentifié auprès d’une application native et que celle-ci doive appeler une API web.Imagine that a user has authenticated on a native application, and this native application needs to call a web API. Azure AD émet un jeton d’accès JWT pour appeler l’API web.Azure AD issues a JWT access token to call the web API. Si l’API web doit appeler une autre API web en aval, elle peut utiliser le flux « au nom de » pour déléguer l’identité de l’utilisateur et s’authentifier auprès de l’API web de deuxième niveau.If the web API needs to call another downstream web API, it can use the on-behalf-of flow to delegate the user’s identity and authenticate to the second-tier web API.

DiagrammeDiagram

Diagramme Application démon ou serveur vers API web

Description du flux du protocoleDescription of protocol flow

Identité d’application avec octroi d’informations d’identification client OAuth 2.0Application identity with OAuth 2.0 client credentials grant
  1. Tout d’abord, l’application serveur doit s’authentifier auprès d’Azure AD avec sa propre identité, sans intervention humaine par le biais d’une boîte de dialogue interactive d’ouverture de session par exemple.First, the server application needs to authenticate with Azure AD as itself, without any human interaction such as an interactive sign-on dialog. Elle envoie une demande au point de terminaison de jeton d’Azure AD, avec les informations d’identification, l’ID d’application et l’URI ID d’application.It makes a request to Azure AD’s token endpoint, providing the credential, Application ID, and application ID URI.
  2. Azure AD authentifie l’application et renvoie un jeton d’accès JWT, qui est utilisé pour appeler l’API web.Azure AD authenticates the application and returns a JWT access token that is used to call the web API.
  3. Sur HTTPS, l’application web utilise le jeton d’accès JWT renvoyé pour ajouter la chaîne JWT avec la mention « porteur » dans l’en-tête d’autorisation de la demande adressée à l’API web.Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. L’API web valide ensuite le jeton JWT et, si la validation réussit, renvoie la ressource souhaitée.The web API then validates the JWT token, and if validation is successful, returns the desired resource.
Identité d’utilisateur délégué avec spécification préliminaire « Au nom de » OAuth 2.0Delegated user identity with OAuth 2.0 On-Behalf-Of Draft Specification

Le flux présenté ci-après part du principe qu’un utilisateur a été authentifié auprès d’une autre application (telle qu’une application native) et que son identité d’utilisateur a été utilisée pour obtenir un jeton d’accès à l’API web de premier niveau.The flow discussed below assumes that a user has been authenticated on another application (such as a native application), and their user identity has been used to acquire an access token to the first-tier web API.

  1. L’application native envoie le jeton d’accès à l’API web de premier niveau.The native application sends the access token to the first-tier web API.
  2. L’API web de premier niveau envoie une demande au point de terminaison de jeton d’Azure AD, en fournissant son ID d’application et ses informations d’identification, ainsi que le jeton d’accès de l’utilisateur.The first-tier web API sends a request to Azure AD’s token endpoint, providing its Application ID and credentials, as well as the user’s access token. La demande est également envoyée avec un paramètre on_behalf_of, qui indique que l’API web demande de nouveaux jetons pour appeler une API web en aval au nom de l’utilisateur d’origine.In addition, the request is sent with an on_behalf_of parameter that indicates the web API is requesting new tokens to call a downstream web API on behalf of the original user.
  3. Azure AD vérifie que l’API web de premier niveau est autorisée à accéder à l’API web de deuxième niveau et valide la demande en renvoyant un jeton d’accès JWT et un jeton d’actualisation JWT à l’API web de premier niveau.Azure AD verifies that the first-tier web API has permissions to access the second-tier web API and validates the request, returning a JWT access token and a JWT refresh token to the first-tier web API.
  4. Sur HTTPS, l’API web de premier niveau appelle ensuite l’API web de deuxième niveau en ajoutant la chaîne de jeton dans l’en-tête d’autorisation de la demande.Over HTTPS, the first-tier web API then calls the second-tier web API by appending the token string in the Authorization header in the request. L’API web de premier niveau peut continuer à appeler l’API web de deuxième niveau tant que le jeton d’accès et les jetons d’actualisation sont valides.The first-tier web API can continue to call the second-tier web API as long as the access token and refresh tokens are valid.

Exemples de codeCode samples

Consultez les exemples de code pour les scénarios du type application démon ou serveur vers API web.See the code samples for Daemon or Server Application to Web API scenarios. Et consultez régulièrement cette page à laquelle nous ajoutons fréquemment de nouveaux exemples.And, check back frequently -- new samples are added frequently. Application serveur ou démon vers API webServer or Daemon Application to Web API

InscriptionRegistering

  • Application à client unique : pour les identités d’application et les identités d’utilisateur délégué, l’application démon ou serveur doit être inscrite dans le même annuaire dans Azure AD.Single Tenant: For both the application identity and delegated user identity cases, the daemon or server application must be registered in the same directory in Azure AD. L’API web peut être configurée pour exposer un ensemble d’autorisations utilisées pour limiter l’accès de l’application démon ou serveur à ses ressources.The web API can be configured to expose a set of permissions, which are used to limit the daemon or server’s access to its resources. Si une identité d’utilisateur délégué est utilisée, l’application serveur doit sélectionner les autorisations souhaitées dans le menu déroulant « Autorisations pour d’autres applications » du portail Azure.If a delegated user identity type is being used, the server application needs to select the desired permissions from the “Permissions to Other Applications” drop-down menu in the Azure portal. Cette étape n’est pas requise si une identité d’application est utilisée.This step is not required if the application identity type is being used.
  • Application mutualisée : tout d’abord, l’application démon ou serveur est configurée pour indiquer les autorisations dont elle a besoin pour fonctionner.Multi-Tenant: First, the daemon or server application is configured to indicate the permissions it requires to be functional. Cette liste d’autorisations requises s’affiche dans une boîte de dialogue quand un utilisateur ou un administrateur de l’annuaire de destination donne son consentement à l’application, ce qui la met à disposition de son organisation.This list of required permissions is shown in a dialog when a user or administrator in the destination directory gives consent to the application, which makes it available to their organization. Certaines applications nécessitent uniquement des autorisations au niveau utilisateur pour lesquelles tous les utilisateurs de l’organisation peuvent donner leur consentement.Some applications only require user-level permissions, which any user in the organization can consent to. D’autres nécessitent des autorisations administrateur, pour lesquelles un utilisateur de l’organisation ne peut pas donner son consentement.Other applications require administrator-level permissions, which a user in the organization cannot consent to. Seul un administrateur d’annuaires peut donner son consentement aux applications qui requièrent des autorisations de ce niveau.Only a directory administrator can give consent to applications that require this level of permissions. Quand un utilisateur ou un administrateur donne son consentement, les deux API web sont inscrites dans son annuaire.When the user or administrator consents, both of the web APIs are registered in their directory.

Expiration du jetonToken expiration

Quand la première application utilise son code d’autorisation pour obtenir un jeton d’accès JWT, elle reçoit également un jeton d’actualisation JWT.When the first application uses its authorization code to get a JWT access token, it also receives a JWT refresh token. À l’expiration du jeton d’accès , le jeton d’actualisation peut être utilisé pour authentifier l’utilisateur à nouveau sans lui demander ses informations d’identification.When the access token expires, the refresh token can be used to re-authenticate the user without prompting for credentials. Ce jeton d’actualisation est ensuite utilisé pour authentifier l’utilisateur, ce qui donne lieu à la création d’un nouveau jeton d’accès et d’un nouveau jeton d’actualisation.This refresh token is then used to authenticate the user, which results in a new access token and refresh token.

Voir aussiSee Also

Guide du développeur Azure Active DirectoryAzure Active Directory Developer's Guide

Exemples de code Azure Active DirectoryAzure Active Directory Code Samples

Informations importantes sur la substitution des clés de signature dans Azure ADImportant Information About Signing Key Rollover in Azure AD

OAuth 2.0 dans Azure ADOAuth 2.0 in Azure AD