Comprendre OAuth 2.0
OAuth 2.0 est un standard permettant à des services d’accéder aux données d’autres services via une autorisation du propriétaire de celles-ci, sans nécessiter la communication de mots de passe. Contrairement à SAML, qui est un standard de fédération d’identité, OAuth 2.0 se concentre sur la délégation d’autorisation.
La fédération d'identité est une méthode permettant de relier l'identité d'un utilisateur à travers différents systèmes de gestion d'identité. Cela permet aux utilisateurs de naviguer facilement entre ces systèmes tout en assurant la sécurité. Par exemple, si vous vous connectez à Google et accédez ensuite à un autre site web sans devoir vous reconnecter, vous utilisez un système de fédération d'identité.
Étapes clés du fonctionnement OAuth 2.0
Prenons l’exemple suivant : un utilisateur souhaite importer des données d’une application B dans une application A.
- L’utilisateur demande à l’application A de contacter l’application B.
- L’utilisateur est redirigé par l’application A vers l’application B et s’authentifie sur cette dernière.
- L’application B demande alors à l’utilisateur s’il autorise l’application A à accéder aux ressources hébergées dans l’application B. Si l’utilisateur donne son autorisation, l’application B envoie un code d’autorisation au navigateur web de l’utilisateur.
- Ce code est ensuite communiqué à l’application A.
- L’application A envoie ce code à l’application B pour obtenir un jeton d’accès en échange. Ce jeton permet d’éviter de communiquer les identifiants de l’utilisateur de l’application B à l’application A.
- Le jeton d’accès est transmis à l’application A.
- L’application A peut alors utiliser ce jeton d’accès pour demander les données de l’application B.
Il est important de comprendre que dans les étapes 3 et 4, trois acteurs sont impliqués : l’application A, le navigateur et l’application B. À ce stade, l’application B envoie un code d’autorisation au navigateur de l’utilisateur, qui le transmet ensuite à l’application A. Ce code d’autorisation prouve que l’utilisateur a donné son accord pour l’accès.
Dans les étapes 6 et 7, seuls deux acteurs sont impliqués : l’application A et l’application B. L’application A envoie le code d’autorisation à l’application B pour obtenir un jeton d’accès en échange. Ce jeton permet à l’application A de solliciter les données de l’application B sans avoir à utiliser les identifiants de l’utilisateur.
L’objectif est de sécuriser le processus en évitant que le jeton d’accès ne soit exposé directement au navigateur de l’utilisateur, ce qui réduit le risque que des tiers malveillants puissent accéder au jeton.