Menu

OAuth 2.0 : Qu'est-ce que c'est ?

6 min de lecture Mis à jour le 02 Avr 2026

Définition

OAuth 2.0 est un protocole d'autorisation standard qui permet à une application tierce d'accéder aux ressources d'un utilisateur sur un autre service, sans partager ses identifiants. Il est à la base du « Se connecter avec Google/Facebook » et de la sécurisation des API modernes.

Qu'est-ce que OAuth 2.0 ?

OAuth 2.0 est un protocole d'autorisation standardisé (RFC 6749) qui permet à une application (le « client ») d'accéder aux ressources protégées d'un utilisateur hébergées par un service tiers (le « serveur de ressources »), avec le consentement explicite de l'utilisateur, sans jamais exposer ses identifiants de connexion. Concrètement, lorsque vous cliquez sur « Se connecter avec Google » sur un site, c'est OAuth 2.0 qui orchestre l'échange : Google confirme votre identité et accorde au site un token d'accès limité, sans que le site ne connaisse votre mot de passe Google.

OAuth 2.0 distingue clairement l'authentification (qui êtes-vous ?) de l'autorisation (à quoi avez-vous accès ?). Le protocole se concentre sur l'autorisation, tandis qu'OpenID Connect (OIDC), une couche construite au-dessus d'OAuth 2.0, ajoute la dimension d'authentification. Ensemble, ils forment le socle de la gestion d'identité moderne pour les applications web et mobiles.

Le protocole définit quatre rôles : le resource owner (l'utilisateur), le client (l'application qui demande l'accès), l'authorization server (qui émet les tokens) et le resource server (qui héberge les données protégées). Cette séparation des responsabilités permet une architecture flexible et sécurisée, adaptée aussi bien aux applications web classiques qu'aux applications mobiles, aux single-page applications et aux communications machine-to-machine.

Pourquoi OAuth 2.0 est important

OAuth 2.0 est devenu le standard universel d'autorisation sur le web. Son adoption massive par les géants du numérique et les entreprises de toutes tailles en fait un composant incontournable de l'architecture applicative moderne.

  • Sécurité des identifiants : les utilisateurs n'ont jamais à partager leur mot de passe avec les applications tierces. Seuls des tokens à durée de vie limitée et à portée restreinte sont échangés.
  • Single Sign-On (SSO) : OAuth 2.0 / OIDC permet aux utilisateurs de se connecter à de multiples applications avec un seul compte (Google, Microsoft, entreprise), simplifiant l'expérience et renforçant la sécurité.
  • Contrôle granulaire des permissions : les scopes OAuth définissent précisément ce à quoi l'application a accès (lecture du profil, accès au calendrier, envoi d'emails), limitant les privilèges au strict nécessaire.
  • Révocabilité : l'utilisateur peut révoquer l'accès d'une application à tout moment depuis les paramètres du fournisseur d'identité, sans changer son mot de passe.
  • Conformité RGPD : le consentement explicite et la granularité des permissions OAuth s'alignent avec les principes du RGPD en matière de minimisation des données et de consentement éclairé.

Comment ça fonctionne

OAuth 2.0 définit plusieurs flux (grant types) adaptés à différents cas d'usage. Le plus courant est le Authorization Code Flow, utilisé pour les applications web serveur. L'utilisateur est redirigé vers le serveur d'autorisation (Google, Microsoft) où il s'identifie et consent à partager certaines données. Le serveur d'autorisation redirige ensuite l'utilisateur vers l'application avec un code d'autorisation temporaire. L'application échange ce code contre un access token et un refresh token en contactant le serveur d'autorisation directement (server-to-server), empêchant l'exposition des tokens dans le navigateur.

Pour les single-page applications (React, Vue), le Authorization Code Flow with PKCE (Proof Key for Code Exchange) ajoute une protection contre l'interception du code d'autorisation. Le client génère un code_verifier aléatoire, en dérive un code_challenge envoyé avec la requête d'autorisation, et prouve sa légitimité en présentant le code_verifier lors de l'échange du code.

Le Client Credentials Flow est utilisé pour les communications machine-to-machine (M2M), par exemple entre des microservices ou des appareils IoT, où il n'y a pas d'utilisateur humain. L'application s'authentifie directement avec son client_id et son client_secret pour obtenir un access token. Les access tokens sont généralement émis au format JWT, permettant une vérification locale sans contacter le serveur d'autorisation.

Exemple concret

Chez Kern-IT, nous intégrons OAuth 2.0 dans nos applications Django pour offrir une authentification moderne et sécurisée. Dans une plateforme métier pour un client du secteur immobilier, nous avons implémenté le SSO via Microsoft Entra ID (anciennement Azure AD) avec django-allauth. Les utilisateurs de l'entreprise cliente se connectent avec leurs identifiants Microsoft existants, sans créer de compte supplémentaire. Les scopes OAuth configurés donnent accès au profil et à l'email, mais pas aux fichiers OneDrive ni au calendrier, conformément au principe de moindre privilège.

Pour les intégrations machine-to-machine de notre plateforme IoT, les services backend utilisent le Client Credentials Flow pour communiquer entre eux de manière sécurisée. Les Raspberry Pi déployés sur le terrain s'authentifient avec des tokens de service via un flux adapté, et les données remontent vers KERN MAP en passant par une API protégée par OAuth 2.0 avec des scopes spécifiques (read:sensors, write:alerts).

Mise en oeuvre

  1. Choisir le flux approprié : Authorization Code with PKCE pour les applications web et SPA, Client Credentials pour le M2M, Device Code pour les appareils IoT sans navigateur.
  2. Configurer le fournisseur d'identité : enregistrez votre application auprès du serveur d'autorisation (Google, Microsoft Entra ID, Keycloak) et obtenez client_id et client_secret.
  3. Intégrer django-allauth ou django-oauth-toolkit : django-allauth pour consommer l'OAuth d'un fournisseur externe (SSO), django-oauth-toolkit pour transformer votre application Django en serveur OAuth 2.0.
  4. Définir les scopes : limitez les permissions demandées au strict nécessaire pour votre cas d'usage, conformément au RGPD et au principe de moindre privilège.
  5. Sécuriser les tokens : stockez les access tokens en mémoire côté client et les refresh tokens dans des cookies HttpOnly. Configurez des durées de vie courtes pour les access tokens.
  6. Implémenter la déconnexion complète : lors de la déconnexion, révoquez les tokens auprès du serveur d'autorisation en plus de supprimer la session locale.

Technologies et outils associés

  • django-allauth : bibliothèque Django complète pour l'authentification sociale (Google, Facebook, Microsoft, GitHub) via OAuth 2.0 / OIDC.
  • django-oauth-toolkit : implémentation complète d'un serveur OAuth 2.0 / OIDC pour Django, conforme RFC 6749.
  • Keycloak : serveur d'identité open source (Red Hat) supportant OAuth 2.0, OIDC, SAML et la gestion fine des rôles et permissions.
  • Microsoft Entra ID : service d'identité cloud de Microsoft, largement utilisé par les entreprises belges et européennes pour le SSO.
  • OpenID Connect (OIDC) : couche d'authentification construite sur OAuth 2.0, ajoutant l'ID token et les endpoints de découverte.
  • JWT : format de token standard utilisé par OAuth 2.0 pour les access tokens, permettant une vérification stateless.

Conclusion

OAuth 2.0 est le pilier de l'autorisation et de l'authentification sur le web moderne. Que ce soit pour implémenter le SSO avec Google ou Microsoft, sécuriser les communications entre microservices, ou protéger l'accès aux API IoT, OAuth 2.0 offre un cadre standardisé, flexible et sécurisé. Chez Kern-IT, nous intégrons OAuth 2.0 dans nos applications Django via django-allauth et django-oauth-toolkit, offrant à nos clients belges une expérience d'authentification moderne tout en garantissant la conformité RGPD et les meilleures pratiques de sécurité.

Conseil Pro

Utilisez toujours le flux Authorization Code avec PKCE, même pour les applications serveur. Le PKCE ne coûte rien en complexité et ajoute une protection supplémentaire contre l'interception du code d'autorisation. C'est désormais la recommandation officielle OAuth 2.1.

Un projet en tête ?

Discutons de comment nous pouvons vous aider à concrétiser vos idées.