Azure oauth2 token rest api
Protocoles OAuth 2.0 et OpenID Connect sur la plate-forme d’identité Microsoft
D’après la documentation officielle.
Le point de terminaison de la plateforme d’identités Microsoft pour l’identité en tant que service implémente l’authentification et l’autorisation avec les protocoles standard OpenID Connect (OIDC) et OAuth 2.0, respectivement. Bien que le service soit conforme aux normes, il peut y avoir des différences subtiles entre deux implémentations de ces protocoles. Les informations fournies ici vous seront utiles si vous choisissez d’écrire votre code en envoyant et en gérant directement des requêtes HTTP ou d’utiliser une bibliothèque open source tierce, plutôt que d’utiliser l’une de nos bibliothèques open source.
Les bases
Dans presque tous les flux OAuth 2.0 et OpenID Connect, quatre parties sont impliquées dans l’échange :
- Le serveur d’autorisation est l’identité Microsoft et est responsable de garantir l’identité de l’utilisateur, d’accorder et de révoquer l’accès aux ressources et d’émettre des jetons. Le serveur d’autorisation est également connu sous le nom de fournisseur d’identité : il gère en toute sécurité tout ce qui concerne les informations de l’utilisateur, son accès et les relations de confiance entre les parties d’un flux.
- Le propriétaire de la ressource est généralement l’utilisateur final. C’est la partie qui possède les données et qui a le pouvoir d’autoriser les clients à accéder à ces données ou ressources.
- Le client OAuth est votre application, identifiée par son ID d’application. Le client OAuth est généralement la partie avec laquelle l’utilisateur final interagit et il demande des jetons au serveur d’autorisation. Le client doit être autorisé à accéder à la ressource par le propriétaire de la ressource.
- Le serveur de ressources est l’endroit où réside la ressource ou les données. Il fait confiance à la Serveur d’autorisation pour authentifier et autoriser en toute sécurité le client OAuth, et utilise des jetons d’accès Bearer pour s’assurer que l’accès à une ressource peut être accordé.
Inscription d’application
: chaque application qui souhaite accepter à la fois des comptes personnels, professionnels ou scolaires doit être inscrite via l’expérience d’inscription d’applications dans le portail Azure avant de pouvoir connecter ces utilisateurs à l’aide d’OAuth 2.0 ou d’OpenID Connect. Le processus d’inscription de l’application collectera et attribuera quelques valeurs à votre application :
- Un ID d’application qui identifie de manière unique votre application
- Un URI de redirection (facultatif) qui peut être utilisé pour rediriger les réponses vers votre application
- Quelques autres valeurs spécifiques au scénario.
Une
fois inscrite, l’application communique avec la plateforme d’identité Microsoft en envoyant des requêtes au point de terminaison :
où le peut prendre l’une des quatre valeurs différentes :
| Valeur | Description |
|---|---|
| Permet aux utilisateurs disposant de comptes Microsoft personnels et de comptes professionnels/scolaires d’Azure AD de se connecter à l’application. | |
| Permet uniquement aux utilisateurs disposant de comptes professionnels/scolaires d’Azure AD de se connecter à l’application. | |
| Permet uniquement aux utilisateurs disposant d’un compte Microsoft personnel (MSA) de se connecter à l’application. | |
| ou | Autorise uniquement les utilisateurs disposant de comptes professionnels/scolaires d’un locataire Azure AD particulier à se connecter à l’application. Il est possible d’utiliser le nom de domaine convivial du locataire Azure AD ou l’identificateur GUID du locataire. |
Pour apprendre à interagissez avec ces points de terminaison, choisissez un type d’application particulier dans la section Protocoles et suivez les liens pour plus d’informations.
Toute application inscrite dans Azure AD peut utiliser la plateforme d’identité Microsoft, même si elle ne se connecte pas à des comptes personnels. De cette façon, vous pouvez migrer des applications existantes vers la plateforme d’identités Microsoft et MSAL sans recréer votre application.
Les jetons
OAuth 2.0 et OpenID Connect font un usage intensif des jetons de porteur , généralement représentés par des JWT (JSON Web Tokens). Un jeton porteur est un jeton de sécurité léger qui accorde au « porteur » l’accès à une ressource protégée. En ce sens, le « porteur » est toute personne qui reçoit une copie du jeton. Bien qu’une partie doive d’abord s’authentifier auprès de la plateforme d’identité Microsoft pour recevoir le jeton porteur, si les étapes requises ne sont pas prises pour sécuriser le jeton lors de la transmission et stockage, il peut être intercepté et utilisé par une partie non prévue. Alors que certains jetons de sécurité disposent d’un mécanisme intégré pour empêcher les parties non autorisées de les utiliser, les jetons porteurs ne disposent pas de ce mécanisme et doivent être transportés dans un canal sécurisé tel que la sécurité de la couche de transport (HTTPS). Si un jeton au porteur est transmis en clair, une partie malveillante peut utiliser une attaque de l’intercepteur pour acquérir le jeton et l’utiliser pour un accès non autorisé à une ressource protégée. Les mêmes principes de sécurité s’appliquent lors du stockage ou de la mise en cache des jetons de porteur pour une utilisation ultérieure. Assurez-vous toujours que votre application transmet et stocke les jetons de porteur de manière sécurisée. Pour plus de considérations de sécurité sur les jetons au porteur, voir RFC 6750 Section 5.
Il existe principalement 3 types de jetons utilisés dans OAuth 2.0 / OIDC :
- Les jetons d’accès - jetons qu’un serveur de ressources reçoit d’un client, contenant les autorisations accordées au client.
- Jetons d’ID : jetons qu’un client reçoit du serveur d’autorisation, utilisés pour connecter un utilisateur et obtenir des informations de base à son sujet.
- Jetons d’actualisation : utilisés par un client pour obtenir de nouveaux jetons d’accès et d’ID au fil du temps. Il s’agit de chaînes opaques qui ne sont compréhensibles que par le serveur d’autorisation.