Introduction

En tant que protocole, OAuth 2.0 établit un cadre d'autorisation standardisé, non pas pour authentifier directement un utilisateur, mais pour permettre à des applications tierces d'obtenir un accès sécurisé et délégué à des ressources protégées. Il définit les interactions entre quatre rôles principaux : le propriétaire de la ressource (l'utilisateur), le client (l'application qui demande l'accès), le serveur d'autorisation (gérant l'approbation et l'émission des jetons) et le serveur de ressources (qui héberge les données protégées). Cette séparation des rôles et des responsabilités est fondamentale pour la sécurité et la flexibilité du protocole.

Le coeur du protocole OAuth 2.0 repose sur l'échange de jetons d'accès, étant des informations d'identification spécifiques, de courte durée, et à portée limitée. Lorsqu'un utilisateur accorde son consentement, le serveur d'autorisation émet un jeton d'accès au client, lui permettant de faire des requêtes aux ressources de l'utilisateur sur le serveur de ressources sans que l'application n'ait besoin de connaître les identifiants réels de l'utilisateur. Le protocole spécifie plusieurs "flows" (flux d'autorisation) adaptés à différents scénarios d'applications, qu'il s'agisse d'applications web, mobiles ou de services backend.

Opérant à la couche application du modèle OSI et s'appuyant fortement sur le protocole HTTP, OAuth 2.0 est devenu le protocole de facto pour la délégation d'autorisation sur Internet. Sa nature flexible et extensible a permis le développement de standards complémentaires, comme OpenID Connect, ajoutant des fonctionnalités d'authentification par-dessus OAuth 2.0. Sa conception modulaire et sa robustesse en font un élément essentiel de l'architecture de sécurité de nombreuses applications et services web modernes, garantissant une gestion des accès à la fois efficace et sécurisée.