Web API

Les applications API web sont des applications web qui doivent obtenir des ressources à partir d’une API web. Dans ce scénario, il existe deux types d’identité que l’application web peut utiliser pour authentifier et appeler l’API web :

• Identité de l’application : ce scénario utilise l’octroi d’informations d’identification du client OAuth 2.0 pour s’authentifier en tant qu’application et accéder à l’API web. Lorsque vous utilisez une identité d’application, l’API web peut uniquement détecter que l’application web l’appelle, car l’API web ne reçoit aucune information sur l’utilisateur. Si l’application reçoit des informations sur l’utilisateur, elle est envoyée via le protocole d’application et n’est pas signée par Azure AD. L’API web approuve que l’application web a authentifié l’utilisateur. Pour cette raison, ce modèle est appelé sous-système approuvé.
• Identité utilisateur déléguée : ce scénario peut être effectué de deux manières : OpenID Connect et octroi de code d’autorisation OAuth 2.0 avec un client confidentiel. L’application web obtient un jeton d’accès pour l’utilisateur, qui prouve à l’API web que l’utilisateur a correctement authentifié auprès de l’application web et que l’application web a pu obtenir une identité d’utilisateur déléguée pour appeler l’API web. Ce jeton d’accès est envoyé dans la demande à l’API web, qui autorise l’utilisateur et retourne la ressource souhaitée.

Les types d'identité d'application et d'identité d'utilisateur délégué sont abordés dans le flux ci-dessous. La principale différence entre eux est que l’identité d’utilisateur déléguée doit d’abord acquérir un code d’autorisation avant que l’utilisateur puisse se connecter et accéder à l’API web.

Diagramme

Flux de protocole

Identité de l’application avec l’octroi d’informations d’identification du client OAuth 2.0

1. Un utilisateur est connecté à Azure AD dans l’application web (consultez la section Applications web pour plus d’informations).
2. L’application web doit acquérir un jeton d’accès afin qu’elle puisse s’authentifier auprès de l’API web et récupérer la ressource souhaitée. Il effectue une requête au point de terminaison du jeton d'Azure AD, en fournissant les informations d'identification, l'ID de l'application et l'URI de l'ID de l'application de l'API web.
3. Azure AD authentifie l’application et retourne un jeton d’accès JWT utilisé pour appeler l’API web.
4. Sur HTTPS, l’application web utilise le jeton d’accès JWT retourné pour ajouter la chaîne JWT avec une désignation « Porteur » dans l’en-tête d’autorisation de la requête à l’API web. L’API web valide ensuite le jeton JWT et, si la validation réussit, retourne la ressource souhaitée.

Identité d’utilisateur déléguée avec OpenID Connect

1. Un utilisateur est connecté à une application web à l’aide d’Azure AD (voir la section Navigateur web vers application web ci-dessus). Si l’utilisateur de l’application web n’a pas encore consenti à autoriser l’application web à appeler l’API web pour son compte, l’utilisateur doit donner son consentement. L’application affiche les autorisations requises et, si l’une de ces autorisations est au niveau de l’administrateur, un utilisateur normal dans l’annuaire ne pourra pas donner son consentement. Ce processus de consentement s’applique uniquement aux applications multilocataires, et non aux applications à locataire unique, car l’application dispose déjà des autorisations nécessaires. Lorsque l’utilisateur s’est connecté, l’application web a reçu un jeton d’ID avec des informations sur l’utilisateur, ainsi qu’un code d’autorisation.
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 qui inclut le code d’autorisation, les détails sur l’application cliente (ID d’application et URI de redirection) et la ressource souhaitée (URI d’ID d’application pour l’API web).
3. Le code d’autorisation et les informations sur l’application web et l’API web sont validés par Azure AD. Une fois la validation réussie, Azure AD retourne deux jetons : un jeton d’accès JWT et un jeton d’actualisation JWT.
4. Sur HTTPS, l’application web utilise le jeton d’accès JWT retourné pour ajouter la chaîne JWT avec une désignation « Porteur » dans l’en-tête d’autorisation de la requête à l’API web. L’API web valide ensuite le jeton JWT et, si la validation réussit, retourne la ressource souhaitée.

Identité utilisateur déléguée avec octroi de code d’autorisation OAuth 2.0

1. Un utilisateur est déjà connecté à une application web, dont le mécanisme d’authentification est indépendant d’Azure AD.
2. L’application web nécessite un code d’autorisation pour acquérir un jeton d’accès, afin qu’elle émet une demande via le navigateur vers le point de terminaison d’autorisation d’Azure AD, en fournissant l’ID d’application et l’URI de redirection de l’application web après l’authentification réussie. L’utilisateur se connecte à Azure AD.
3. Si l’utilisateur de l’application web n’a pas encore consenti à autoriser l’application web à appeler l’API web pour son compte, l’utilisateur doit donner son consentement. L’application affiche les autorisations requises et, si l’une de ces autorisations est au niveau de l’administrateur, un utilisateur normal dans l’annuaire ne pourra pas donner son consentement. Ce consentement s’applique à la fois à une application monolocataire et mutualisée. Dans le cas d'un locataire unique, un administrateur peut accorder le consentement administrateur au nom de ses utilisateurs. Pour ce faire, utilisez le bouton Grant Permissions dans le portail Azure .
4. Une fois que l’utilisateur a consenti, l’application web reçoit le code d’autorisation dont il a besoin pour acquérir un jeton d’accès.
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 qui inclut le code d’autorisation, les détails sur l’application cliente (ID d’application et URI de redirection) et la ressource souhaitée (URI d’ID d’application pour l’API web).
6. Le code d’autorisation et les informations sur l’application web et l’API web sont validés par Azure AD. Une fois la validation réussie, Azure AD retourne deux jetons : un jeton d’accès JWT et un jeton d’actualisation JWT.
7. Sur HTTPS, l’application web utilise le jeton d’accès JWT retourné pour ajouter la chaîne JWT avec une désignation « Porteur » dans l’en-tête d’autorisation de la requête à l’API web. L’API web valide ensuite le jeton JWT et, si la validation réussit, retourne la ressource souhaitée.

Exemples de code

Consultez les exemples de code pour les scénarios d’application web vers l’API web. Et, vérifiez fréquemment : de nouveaux exemples sont ajoutés fréquemment. Application web vers l’API web.

Inscription d’application

Pour inscrire une application auprès du point de terminaison Azure AD v1.0, consultez Inscrire une application.

• Locataire unique : pour les cas d’identité d’utilisateur délégué et d’identité d’utilisateur déléguée, l’application web et l’API web doivent être inscrits dans le même répertoire dans Azure AD. L’API web peut être configurée pour exposer un ensemble d’autorisations, qui sont utilisées pour limiter l’accès de l’application web à ses ressources. Si un type d’identité d’utilisateur délégué est utilisé, l’application web doit sélectionner les autorisations souhaitées dans le menu déroulant Autorisations d’autres applications dans le portail Azure. Cette étape n’est pas nécessaire si le type d’identité de l’application est utilisé.
• Multilocataire : tout d’abord, l’application web est configurée pour préciser les autorisations dont elle a besoin afin de rester fonctionnelle. Cette liste d’autorisations requises s’affiche dans une boîte de dialogue lorsqu’un utilisateur ou un administrateur du répertoire de destination donne son consentement à l’application, ce qui le rend disponible pour son organisation. Certaines applications nécessitent uniquement des autorisations au niveau de l’utilisateur, auxquelles tout utilisateur de l’organisation peut donner son consentement. D’autres applications nécessitent des autorisations au niveau de l’administrateur, auxquelles un utilisateur de l’organisation ne peut pas consentir. Seul un administrateur d’annuaire peut donner son consentement aux applications qui nécessitent ce niveau d’autorisations. Lorsque l’utilisateur ou l’administrateur consent, l’application web et l’API web sont tous deux inscrits dans leur annuaire.

Expiration du jeton

Lorsque 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. Lorsque le jeton d’accès expire, le jeton d’actualisation peut être utilisé pour réauthentifier l’utilisateur sans qu’il soit nécessaire de se reconnecter. Ce jeton d’actualisation est ensuite utilisé pour authentifier l’utilisateur, ce qui entraîne un nouveau jeton d’accès et un jeton d’actualisation.

Étapes suivantes

• En savoir plus sur les autres types et scénarios d’application
• En savoir plus sur les principes de base de l’authentification azure AD