OAuth est un protocole ouvert d’autorisation déléguée qui permet à une application tierce d’accéder à des ressources protégées (ex. : profil utilisateur, emails, fichiers) sans jamais connaître le mot de passe de l’utilisateur.
Principe fondamental :
« Accorde un accès limité, temporaire et contrôlé — sans partager tes identifiants. »
Comment ça marche ?
- Une application (ex. : une app de planning) demande l’accès à votre compte Google.
- Vous êtes redirigé·e vers Google (le fournisseur d’identité).
- Vous autorisez explicitement l’accès à certaines données (ex. : « Voir vos contacts »).
- Google délivre un jeton d’accès (access token) à l’application.
- L’application utilise ce jeton pour accéder aux données sans jamais voir votre mot de passe.
Ce n’est pas un protocole d’authentification (comme SAML ou OpenID Connect), mais d’autorisation.
Cependant, il est souvent utilisé en complément d’OpenID Connect pour l’authentification.
Cas d’usage courants
- « Se connecter avec Google / GitHub / Facebook »
- Applications mobiles accédant à votre calendrier, photos ou cloud
- Intégrations entre outils (ex. : Zapier, Make)
- APIs sécurisées (ex. : accès à l’API Twitter ou LinkedIn)
Enjeux critiques
Avantages
- Sécurité renforcée : pas de partage de mot de passe
- Contrôle granulaire : vous choisissez les permissions (lecture seule, accès limité)
- Révocation facile : vous pouvez retirer l’accès à tout moment (dans les paramètres de votre compte)
Risques
- Sur-autorisation : beaucoup d’applications demandent plus de droits qu’elles n’en ont besoin (« accès à tous vos emails » pour un simple import de contacts).
- Abus de confiance : si l’application tierce est compromise, le jeton peut être détourné.
- Opacité : les utilisateurs ne comprennent souvent pas ce qu’ils autorisent.
- Centralisation : renforce la dépendance aux géants (Google, Meta) comme fournisseurs d’identité.
Dans une démarche de souveraineté numérique, OAuth est utile… mais il faut limiter son usage aux cas strictement nécessaires et préférer des fournisseurs d’identité éthiques ou auto-hébergés (ex. : Keycloak, Nextcloud ID).
Bonnes pratiques (pour développeurs et RSSI)
- Toujours demander le scope minimal (principe du moindre privilège)
- Utiliser PKCE (Proof Key for Code Exchange) pour les apps mobiles et SPAs
- Préférer OAuth 2.1 (plus sécurisé que 2.0)
- Auditer régulièrement les applications autorisées dans les comptes professionnels
Synonymes / termes associés
- Délégation d’autorisation
- Jeton d’accès (access token)
- Authentification fédérée (quand combiné à OpenID Connect)
- SSO léger (Single Sign-On)