OAuth

OAuth est un protocole d'autorisation qui permet à un utilisateur d'accorder à une application un accès limité et révocable à ses données sur un autre service, sans partager son mot de passe. C'est le mécanisme derrière la quasi-totalité des boutons « Se connecter avec Google » ou « Connecter votre compte Slack » : au lieu de saisir un mot de passe dans une application tierce, l'utilisateur approuve un périmètre de permissions précis et l'application reçoit un jeton qu'elle peut utiliser en son nom.

Qu'est-ce qu'OAuth ?

OAuth (Open Authorization) sépare deux notions longtemps confondues : l'authentification, prouver qui vous êtes, et l'autorisation, décider ce qu'une application a le droit de faire en votre nom. La version actuelle, OAuth 2.0, publiée en 2012, est la norme du secteur pour l'accès délégué sur le web. Avant OAuth, connecter un service à un autre signifiait transmettre un mot de passe directement : le tiers obtenait un accès illimité, l'utilisateur n'avait aucun moyen simple de voir ce qui était partagé, et révoquer l'accès imposait de changer le mot de passe partout où il était réutilisé. Les approches antérieures comme l'authentification HTTP Basic envoyaient ce même identifiant statique à chaque requête, si bien qu'un journal serveur exposé ou une intégration tierce compromise dévoilait le vrai mot de passe de l'utilisateur, pas seulement un jeton à usage limité.

Comment fonctionne le flux OAuth

Un échange OAuth 2.0 classique (le flux « authorization code », utilisé par la plupart des applications web et mobiles) suit quatre étapes : l'application redirige l'utilisateur vers l'écran de connexion et de consentement du service, l'utilisateur approuve un ensemble précis de permissions (scopes), le service redirige en retour avec un code d'autorisation de courte durée, et l'application échange ce code contre un jeton d'accès sur son serveur. Une requête d'autorisation simplifiée ressemble à ceci :

GET /authorize?client_id=abc123&redirect_uri=https://app.exemple.com/callback&response_type=code&scope=read_profile
Authorization: Bearer <access_token>

Le jeton d'accès est ce que l'application stocke réellement et envoie à chaque appel API. Il est limité à des permissions précises, possède une date d'expiration, et peut être révoqué par l'utilisateur à tout moment depuis les paramètres de son compte, sans toucher à son mot de passe. La plupart des implémentations délivrent aussi un refresh token de plus longue durée en parallèle, pour que l'application puisse obtenir discrètement un nouveau jeton d'accès une fois l'ancien expiré, sans repasser par l'écran de connexion. Faire tourner ces refresh tokens, en émettre un nouveau à chaque usage et invalider le précédent, limite encore les dégâts si un jeton venait à être intercepté en transit.

Les principaux types d'autorisation OAuth

• Authorization code : le flux standard pour les applications avec un back-end serveur, l'option la plus sûre.
• Authorization code avec PKCE : le même flux renforcé pour les applications mobiles et les single-page apps qui ne peuvent pas garder un secret en sécurité.
• Client credentials : utilisé pour les appels serveur à serveur, sans utilisateur final impliqué.
• Refresh token : pas une autorisation en soi, mais le mécanisme qui permet à une application d'obtenir un nouveau jeton d'accès une fois le précédent expiré, sans redemander la connexion à l'utilisateur.

OAuth vs OpenID Connect vs clé API

Bonnes pratiques et pièges courants

Toujours demander le périmètre le plus étroit dont l'application a réellement besoin : réclamer un accès complet au compte alors que seule une photo de profil est nécessaire est une source fréquente de méfiance côté utilisateur et de remarque en audit. Utiliser l'extension PKCE pour toute application incapable de stocker un secret client en sécurité, ce qui couvre aujourd'hui quasiment toutes les applications mobiles et single-page. Stocker les jetons d'accès et de rafraîchissement chiffrés, jamais en clair ni dans un stockage côté client accessible à d'autres scripts. Faire expirer les jetons d'accès rapidement, en général en quelques minutes à quelques heures, et s'appuyer sur les refresh tokens pour la durée, plutôt que d'émettre un jeton d'accès valable plusieurs mois. L'erreur la plus fréquente est de considérer une connexion OAuth comme la preuve d'un e-mail ou d'une identité vérifiée : OAuth seul prouve seulement que l'utilisateur a accordé un accès, c'est OpenID Connect qui ajoute une couche d'identité vérifiée par-dessus.

Pourquoi OAuth compte

OAuth rend possible le fonctionnement moderne des applications connectées et des intégrations, sans que chaque service ait besoin de stocker le mot de passe de tout le monde. Pour une équipe qui met en place des automatisations (un CRM qui récupère des contacts depuis Gmail, un outil de projet synchronisé avec Slack), c'est la manière standard d'autoriser cette connexion en sécurité, avec une traçabilité et un moyen simple de couper l'accès plus tard. Une équipe marketing qui connecte sa régie publicitaire à un tableau de bord de reporting, ou une équipe support qui relie son helpdesk à un CRM, s'appuient toutes deux sur le même mécanisme pour faire circuler des données en sécurité entre des systèmes qui n'ont jamais été conçus par le même éditeur.

OAuth chez BeBranded

Nous mettons en place OAuth dès qu'une application web doit se connecter à une API tierce au nom d'un utilisateur : synchroniser un agenda, récupérer des données CRM, ou permettre à un client de se connecter avec un compte existant plutôt que de créer un nouveau mot de passe. Cela fait partie intégrante des applications web que nous construisons dès qu'une intégration le justifie.