OAuth 2.0 est un standard moderne qui permet de se connecter à des applications et des sites web sans créer de nouveau mot de passe. Grâce à lui, vous pouvez cliquer sur " Se connecter avec Google ", " Se connecter avec Facebook " ou " Se connecter avec GitHub " et accéder à un service en quelques clics, sans transmettre votre mot de passe au site tiers : tout repose sur un mécanisme sécurisé de jetons. Découvrez dans cet article le fonctionnement d'OAuth 2.0, les coulisses techniques et pourquoi cette méthode est plus sûre qu'une connexion classique.
OAuth 2.0 expliqué simplement
OAuth 2.0 permet à un service d'accéder de façon limitée à vos données d'un autre service, sans jamais partager votre mot de passe.
Exemple concret :
- Vous arrivez sur un site et cliquez sur " Se connecter avec Google ".
- Le site ne connaît ni ne reçoit jamais votre mot de passe Google. À la place, Google vous demande :
" Autoriser ce site à accéder à votre adresse e-mail et à votre nom ? "
Si vous acceptez, Google remet au site un jeton spécial (token) qui n'accorde l'accès qu'aux données autorisées.
Pourquoi utiliser OAuth ?
Avant, chaque site exigeait :
- la création d'un nouveau compte
- l'invention d'un mot de passe
- et son stockage (parfois peu sécurisé)
OAuth résout plusieurs problèmes :
- connexion simplifiée (1 clic au lieu d'une inscription)
- réduction du risque de fuite de mots de passe
- contrôle total sur les accès à vos données
Autorisation vs authentification
La distinction est essentielle (et souvent source de confusion) :
- Authentification : qui êtes-vous ? (connexion à un compte)
- Autorisation : à quoi avez-vous accès ? (accès aux données)
OAuth 2.0 concerne avant tout l'autorisation, même s'il est fréquemment combiné à d'autres technologies pour proposer une authentification via Google.
Où OAuth est-il utilisé ?
- Connexion avec Google, Facebook, Apple
- Autorisation via les réseaux sociaux dans des applications
- Connexion de services tiers (ex : bots Telegram, applis connectées)
- Intégrations API entre services
Connexion Google ≠ transmission du mot de passe
Contrairement à une idée reçue, cliquer sur " Se connecter avec Google " ne transmet jamais votre mot de passe au site : il reste chez Google.
Que se passe-t-il concrètement ?
- Le site vous redirige vers la page de connexion Google
- Vous saisissez votre mot de passe uniquement sur Google
- Google vous demande d'autoriser l'accès à certaines informations
- Google renvoie au site un jeton sécurisé après votre accord
Le site ne participe jamais à la saisie du mot de passe : il reçoit juste une autorisation limitée.
Pourquoi OAuth 2.0 est-il plus sûr ?
- Votre mot de passe reste uniquement chez Google
- Les sites tiers obtiennent un accès limité
- Vous pouvez révoquer l'accès à tout moment
Même si un service tiers est compromis, les pirates n'auront jamais votre mot de passe, seulement un jeton temporaire, facilement révoqué.
Quelles données le site reçoit-il ?
- Votre nom
- Votre adresse e-mail
- Votre photo de profil
- Autres données que vous avez autorisées
Important : la liste des autorisations est toujours affichée avant de valider.
Le rôle des jetons (tokens) à la place du mot de passe
- access token : clé d'accès aux données
- refresh token (parfois) : pour renouveler l'accès
C'est la logique : pas " voici mon mot de passe ", mais " voici une autorisation temporaire et limitée ".
Prudence : les risques à connaître
- Fenêtres de connexion falsifiées (phishing)
- Applications suspectes demandant trop de droits
- Connexion via des sites inconnus
Si la page de connexion semble étrange ou que l'adresse n'est pas google.com, ne saisissez pas vos identifiants.
Fonctionnement détaillé d'OAuth 2.0
Pour mieux comprendre OAuth 2.0, voici ce qui se passe " sous le capot " lors d'une connexion avec Google.
Quatre acteurs interviennent :
- L'utilisateur (vous)
- Le client (site ou appli où vous vous connectez)
- Le serveur d'autorisation (Google)
- Le serveur de ressources (API Google avec vos données)
Étape 1 : redirection vers le service (Google)
En cliquant sur " Se connecter avec Google ", le site vous redirige vers la page d'autorisation Google, en précisant :
- qui demande l'accès
- quelles données sont requises
- où vous renvoyer après connexion
C'est le démarrage du " flux OAuth ".
Étape 2 : validation de l'accès
Google affiche :
- Votre compte
- La liste des autorisations (e-mail, profil, etc.)
Vous choisissez d'accepter ou non. Sans accord, aucun accès n'est possible : c'est la base d'OAuth.
Étape 3 : réception d'un code d'autorisation
Si vous acceptez, Google ne donne pas l'accès immédiatement. Il renvoie au site un code temporaire (authorization code), qui seul ne sert à rien : c'est un relais, pas une clé directe.
Étape 4 : échange contre un access token
Le site envoie ce code à Google depuis son serveur et récupère alors :
- un access token
- parfois un refresh token
Le site dispose maintenant d'une " clé d'accès " officielle.
Étape 5 : accès aux données utilisateur
Avec l'access token, le site peut :
- obtenir votre e-mail
- connaître votre nom
- télécharger votre avatar
L'accès est toujours limité à ce que vous avez approuvé.
Principes de sécurité du schéma OAuth
- L'utilisateur fait confiance à Google
- Google fait confiance à l'application (avec votre accord)
- L'application reçoit un accès restreint, jamais un contrôle total
Cela rend le système à la fois pratique et sécurisé.
Access token et refresh token : quelle différence ?
Après une autorisation réussie, le site ne reçoit jamais le mot de passe : il fonctionne uniquement avec des jetons, éléments clés d'OAuth 2.0.
Access token : la clé principale
L'access token est une clé temporaire permettant à une application d'accéder à vos données :
- récupérer votre e-mail
- connaître votre nom
- utiliser des API (Google Drive, Gmail, etc.)
Caractéristiques :
- valable pendant une durée limitée (par ex. 1 heure)
- droits restreints (selon vos autorisations)
- peut être révoqué à tout moment
Il s'agit d'un laissez-passer temporaire, pas d'un accès complet à votre compte.
Refresh token : renouveler l'accès
Le refresh token sert à obtenir un nouvel access token sans que l'utilisateur ait à se reconnecter.
Fonctionnement :
- l'access token expire
- l'application envoie le refresh token à Google
- elle reçoit un nouvel access token
Tout cela se fait automatiquement, sans intervention de l'utilisateur.
Pourquoi deux jetons valent mieux qu'un seul
- l'access token a une durée de vie courte → risque réduit
- le refresh token est stocké de façon sécurisée (côté serveur)
- pas besoin de saisir votre mot de passe à chaque fois
Si un pirate obtient l'access token, il devient rapidement inutilisable.
Où sont stockés les jetons ?
- access token : en mémoire ou temporairement côté client
- refresh token : sur le serveur, de façon sécurisée
Cela diminue les risques de fuite de données sensibles.
Peut-on révoquer l'accès ?
Oui, et c'est un point fort d'OAuth : rendez-vous dans les paramètres de votre compte Google pour :
- voir la liste des applications connectées
- supprimer leur accès
Après cette action, tous les jetons associés deviennent invalides.
À retenir sur OAuth 2.0
- Votre mot de passe n'est jamais transmis : uniquement des jetons (access token et refresh token) sont utilisés
- C'est ce mécanisme qui rend la connexion via Google sûre... à condition d'être bien implémentée
Les principaux types de flux OAuth
OAuth 2.0 n'est pas un scénario unique, mais une série de " flows " (flux) adaptés au contexte : site web, appli mobile ou serveur.
Authorization Code Flow : le plus courant et le plus sûr
Il s'agit du schéma standard utilisé pour la connexion via Google.
- l'utilisateur s'authentifie
- l'application reçoit un authorization code
- le serveur échange ce code contre un access token
Atouts sécurité :
- les jetons ne transitent pas directement par le navigateur
- vérification côté serveur
- possibilité d'ajouter d'autres protections (PKCE)
Utilisation :
- applications web
- applications mobiles modernes
Implicit Flow : un modèle dépassé
Anciennement utilisé pour les applications web sans serveur (SPA), où l'access token est transmis directement, sans échange de code.
Inconvénients :
- le jeton est stocké dans le navigateur
- risque de fuite accru
- sécurité moindre
Ce flow est désormais considéré comme obsolète.
Client Credentials Flow : pour les serveurs
Ce flux s'applique lorsqu'il n'y a pas d'utilisateur final : un serveur communique avec l'API d'un autre service.
Exemple : un service A accède à une API B grâce à ses propres identifiants.
Utilisations typiques :
- microservices
- intégrations backend
- automatisation
Pourquoi ces différences sont importantes ?
- Connexion utilisateur → Authorization Code Flow
- Communication serveur à serveur → Client Credentials
- Anciennes SPA → Implicit (en voie de disparition)
La plupart des connexions via Google utilisent l'Authorization Code Flow.
OAuth 2.0 vs OpenID Connect : quelles différences ?
Beaucoup pensent qu'OAuth 2.0 sert à l'authentification. En réalité, OAuth gère l'accès aux données, pas l'identification de l'utilisateur.
Pourquoi OAuth n'est pas une authentification
OAuth 2.0 répond à la question : " Cet outil peut-il accéder à mes données ? "
Mais il ne répond pas à : " Qui suis-je ? "
L'application obtient votre e-mail, mais ne valide pas formellement votre identité.
Le rôle d'OpenID Connect
OpenID Connect (OIDC) est une extension d'OAuth 2.0 qui ajoute l'authentification grâce à un ID token, qui contient :
- votre identifiant utilisateur
- des informations sur vous
- la preuve que vous êtes bien connecté
Comment fonctionnent-ils ensemble ?
- OAuth 2.0 → donne l'accès aux données
- OpenID Connect → confirme qui vous êtes
Ensemble, ils réalisent une connexion complète et sécurisée.
Analogie simple
- OAuth = une clé pour ouvrir une porte (accès)
- OpenID Connect = un passeport (identité)
Ils remplissent deux fonctions différentes, mais sont complémentaires.
Pourquoi c'est essentiel
- Sans OpenID Connect : impossible de faire une vraie connexion " Se connecter avec Google "
- Sans OAuth : impossible d'accorder un accès sécurisé aux données
C'est pourquoi les services modernes utilisent toujours les deux standards.
Sécurité d'OAuth 2.0
OAuth 2.0 est réputé sûr, à condition d'être correctement implémenté et que l'utilisateur reste vigilant. Voici les mécanismes de protection... et les points de vigilance.
Pourquoi le mot de passe n'est jamais transmis
- Votre mot de passe est saisi uniquement chez Google
- Le site tiers ne le voit jamais et ne le stocke pas
Résultat : moins de risques de :
- fuites de bases de données
- vol de mot de passe
- réutilisation sur d'autres sites
Même si un service tiers est compromis, votre compte Google reste protégé.
Droits d'accès limités
Chaque application demande des autorisations précises :
- e-mail uniquement
- ou accès à vos fichiers
- ou accès à votre agenda
Vous voyez toujours la liste avant de valider. Une application ne peut rien obtenir de plus que ce que vous autorisez.
Des jetons temporaires
- L'access token expire rapidement
- Le refresh token est stocké à part, pour prolonger l'accès
Ce système limite les conséquences d'une éventuelle fuite.
Principaux risques
- Phishing : pages de connexion factices (imitant Google)
- Applications douteuses : demandant trop de droits
- Implémentations non sécurisées : erreurs de développement (fuite de jetons...)
Comment se protéger ?
- Vérifiez toujours l'URL de connexion (doit être google.com)
- N'accordez pas d'accès à des services inconnus
- Contrôlez régulièrement la liste de vos connexions Google
- Activez la double authentification
Quand OAuth est-il vraiment sécurisé ?
- Service officiel
- Fournisseur fiable (Google, Apple, etc.)
- Vous comprenez quelles données sont partagées
OAuth n'est pas sûr " par défaut " : c'est l'attention portée à son usage qui garantit la sécurité.
OAuth 2.0 dans la vie quotidienne
OAuth 2.0 est devenu un standard universel sur Internet : vous l'utilisez probablement tous les jours sans le savoir.
Réseaux sociaux et connexion rapide
Exemples évidents :
- " Se connecter avec Google "
- " Se connecter avec Facebook "
- " Se connecter avec Apple "
Avantages :
- pas de création de compte supplémentaire
- pas de mot de passe à retenir
- accès instantané aux services
Cette méthode est utilisée sur les sites web, applications mobiles, jeux en ligne...
Applications et services cloud
OAuth est courant dans :
- applications de prise de notes
- stockages cloud
- outils CRM et business
- éditeurs en ligne
Exemple : une appli peut accéder à Google Drive pour enregistrer vos fichiers (uniquement avec votre accord).
APIs et intégrations
OAuth est l'épine dorsale des intégrations modernes :
- Un bot Telegram accède à vos données utilisateur
- Un service d'analytics se connecte à Google Analytics
- Une appli synchronise vos événements de calendrier
Avantages : partage sécurisé des données, mots de passe non transmis, accès limité.
Systèmes d'entreprise
En entreprise, OAuth sert à :
- l'authentification unique (SSO)
- la gestion des accès des collaborateurs
- l'intégration des outils internes
Cela simplifie la vie des équipes et renforce la sécurité.
Pourquoi OAuth s'est imposé comme standard
- Expérience utilisateur simplifiée
- Sécurité accrue (pas de partage de mot de passe)
- Souplesse (différents niveaux d'accès)
- Polyvalence (fonctionne sur tous les types de services)
Aujourd'hui, presque tous les services modernes utilisent OAuth ou une technologie équivalente.
Conclusion
OAuth 2.0 est la base de l'autorisation sécurisée sur Internet. Il vous permet d'accéder rapidement à des services sans multiplier les mots de passe.
L'idée clé : vous ne partagez jamais votre mot de passe, mais accordez une autorisation limitée.
OAuth est ainsi à la fois pratique pour l'utilisateur et sûr pour le service. Vous y faites appel chaque jour : connexion via Google, ajout d'une appli, intégration à un service cloud...
Le plus important : surveillez toujours à qui vous accordez un accès et faites confiance uniquement aux services reconnus.
Questions fréquentes sur OAuth 2.0
- Est-il sûr de se connecter via Google ?
Oui, si le site est officiel et que vous voyez la vraie page Google.
- Un site peut-il obtenir mon mot de passe ?
Non, votre mot de passe reste chez Google.
- Que faire si j'ai donné l'accès à une appli ?
Rendez-vous dans les paramètres de votre compte pour révoquer l'accès.
- Quelle différence avec une connexion classique ?
Connexion classique : login + mot de passe.
OAuth : accès via un service tiers, sans transmettre votre mot de passe.