Applications natives

Les applications natives sont des applications qui appellent une API web pour le compte d’un utilisateur. Ce scénario est basé sur le type d’octroi de code d’autorisation OAuth 2.0 avec un client public, comme décrit dans la section 4.1 de la spécification OAuth 2.0. L’application native obtient un jeton d’accès pour l’utilisateur à l’aide du protocole OAuth 2.0. Ce jeton d’accès est ensuite envoyé dans la requête à l’API web, qui autorise l’utilisateur et retourne la ressource souhaitée.

Diagramme

Flux de protocole

Si vous utilisez les bibliothèques d’authentification AD, la plupart des détails du protocole décrits ci-dessous sont gérés pour vous, tels que la fenêtre contextuelle du navigateur, la mise en cache des jetons et la gestion des jetons de renouvellement.

1. À l’aide d’une fenêtre contextuelle de navigateur, l’application native effectue une demande au point de terminaison d’autorisation dans Azure AD. Cette requête inclut l’ID d’application et l’URI de redirection de l’application native, comme indiqué dans le portail Azure et l’URI d’ID d’application pour l’API web. Si l’utilisateur n’a pas encore connecté, il est invité à se reconnecter
2. Azure AD authentifie l’utilisateur. S’il s’agit d’une application multilocataire et qu’il est nécessaire d’utiliser l’application, l’utilisateur doit donner son consentement s’il n’en a pas déjà fait. Une fois le consentement accordé et une fois l’authentification réussie, Azure AD émet une réponse de code d’autorisation à l’URI de redirection de l’application cliente.
3. Quand Azure AD émet 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. À l’aide de ce code d’autorisation, l’application cliente 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).
4. Le code d’autorisation et les informations sur l’application cliente 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. En outre, Azure AD retourne des informations de base sur l’utilisateur, telles que son nom complet et son ID de locataire.
5. Sur HTTPS, l’application cliente 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.
6. Lorsque le jeton d’accès expire, l’application cliente reçoit une erreur indiquant que l’utilisateur doit s’authentifier à nouveau. Si l’application a un jeton d’actualisation valide, elle peut être utilisée pour acquérir un nouveau jeton d’accès sans inviter l’utilisateur à se reconnecter. Si le jeton d’actualisation expire, l’application doit à nouveau authentifier l’utilisateur de manière interactive.

Exemples de code

Consultez les exemples de code pour les scénarios d'interaction d'une application native avec une API web. Et, revenez fréquemment- nous ajoutons de nouveaux exemples fréquemment. Application native à 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 : l’application native et l’API web doivent être inscrites 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 native à ses ressources. L’application cliente sélectionne ensuite les autorisations souhaitées dans le menu déroulant « Autorisations pour d’autres applications » dans le portail Azure.
• Multilocataire : tout d'abord, l'application native a toujours été uniquement enregistrée dans l'annuaire du développeur ou de l'éditeur. Ensuite, l’application native est configurée pour indiquer les autorisations dont elle a besoin pour être 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, seule l’API web est inscrite dans son annuaire.

Expiration du jeton

Lorsque 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. Lorsque le jeton d’accès expire, le jeton d’actualisation peut être utilisé pour authentifier à nouveau 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 d’autres types d’applications et scénarios
• En savoir plus sur les principes de base de l’authentification azure AD