OAuth : qu'est-ce que c'est, cas d'utilisation et un guide rapide pour le comprendre immédiatement

Avez-vous déjà cliqué sur « Connectez-vous avec Google » et êtes allé sur un écran indiquant « cette application veut accéder à votre profil, l'autoriser ? C'est OAuth qui fonctionne. Et presque personne qui l’utilise ne comprend ce qui s’est réellement passé derrière cet écran.

Ce guide rapide explique ce qu'est OAuth, quand il entre en jeu et, plus important encore, et ce qui prête le plus à confusion, quel problème il résout réellement. Ce n'est pas un tutoriel d'implémentation. Il s'agit de la compréhension conceptuelle dont vous aviez besoin pour arrêter de copier les configurations de sécurité sans savoir ce que vous faites.

La confusion commence par le nom. Beaucoup de gens pensent que OAuth sert à « se connecter ». Cela sert, en partie, mais cette vision cache ce qu’elle est réellement. Comprendre cela correctement est ce qui différencie ceux qui utilisent consciencieusement la sécurité de ceux qui se contentent de la répéter.

Qu'est-ce qu'OAuth réellement

OAuth est un protocole d'autorisation, pas une authentification. Cette seule phrase résout déjà la moitié de la confusion sur le sujet.

L'autorisation répond "à quoi cette application peut-elle accéder en mon nom ?". L'authentification répond "qui êtes-vous ?". Ce sont des questions différentes. OAuth a été créé pour la première fois.

L'idée de base : OAuth vous permet de donner à une application un accès limité à vos ressources qui se trouvent dans un autre service, sans transmettre votre mot de passe. Lorsqu'une application de retouche photo demande l'accès à votre Google Drive, vous ne lui donnez pas votre mot de passe Google. Vous l'autorisez et Google donne à l'application une clé temporaire et restreinte, un jeton, qui n'est valable que pour ce que vous avez autorisé.

C’est le génie du protocole : déléguer l’accès sans partager les identifiants. Le mot de passe ne quitte jamais vos mains ni le service d'origine.

L'analogie qui rend tout clair

Pensez au voiturier. Lorsque vous confiez votre voiture à un voiturier, vous ne remettez pas la clé de votre maison ni vos documents, vous remettez une clé qui ne fait que démarrer la voiture et ouvrir la porte, pour une durée limitée, pour un usage précis.

OAuth est cette clé de voiturier pour le monde numérique. Le token qu'il émet a une portée limitée (il ne fait que ce qui a été autorisé), il est temporaire (il expire) et peut être révoqué (vous pouvez l'annuler quand vous le souhaitez, sans changer le mot de passe pour tout). Il s’agit d’une autorisation granulaire, contrôlée et réversible.

Cas d'utilisation où OAuth apparaît

Comprendre des cas concrets fixe le concept.

Le plus visible est le social login, « connectez-vous avec Google, Facebook, Apple ». Ici, OAuth (souvent combiné à une couche d'identité, OpenID Connect) permet à une application de confirmer son identité via un fournisseur de confiance, sans créer un énième mot de passe. C’est un cas que tout le monde connaît, même si c’est pour de mauvaises raisons.

Un autre cas est celui de l'accès entre applications. Un outil de productivité qui lit votre calendrier, une application financière qui se connecte à votre banque via open finance, un système qui publie à votre nom sur un réseau social. Tout le monde utilise OAuth pour obtenir une autorisation limitée sur les ressources hébergées ailleurs.

Il y a aussi le cas des API et des intégrations d'entreprise. Lorsque les systèmes d'une organisation doivent accéder aux données des autres de manière contrôlée et vérifiable, OAuth fournit le mécanisme de jeton étendu. Dans le secteur public et les environnements réglementés, cette capacité à accorder et révoquer un accès granulaire est précieuse pour la conformité.

Le guide rapide du flux

Sans entrer dans le code, le flux essentiel est le suivant : vous (le propriétaire des données) demandez un service à une application. L'application vous redirige vers le service où résident vos données. Vous vous y authentifiez et approuvez l'accès demandé. Le service renvoie un jeton d'accès restreint à l'application. L'application utilise ce jeton pour accéder uniquement à ce que vous avez autorisé, tant que le jeton est valide. Votre mot de passe ne transite jamais par l'application. C'est cette conception qui rend OAuth sécurisé lorsqu'il est bien mis en œuvre.

L'erreur conceptuelle la plus dangereuse

La maturité en matière de sécurité nécessite de comprendre l'erreur qui pose le plus de problèmes : traiter OAuth comme une preuve d'identité alors qu'il s'agit d'une preuve d'autorisation.

OAuth dit "ce jeton peut accéder à une telle ressource". Il ne dit pas, en soi, « cette personne est telle ou telle ». Quiconque utilise OAuth pur comme s’il s’agissait d’une connexion d’identité ouvre de véritables failles. C'est pourquoi OpenID Connect existe, une couche construite sur OAuth précisément pour gérer correctement l'identité. La confusion entre les deux est à l’origine des vulnérabilités classiques de la connexion sociale.

Une autre erreur courante consiste à demander des portées trop larges. Une application qui demande un accès complet alors qu’elle n’en a besoin que d’une partie viole le principe du moindre privilège. En tant qu'utilisateur, méfiez-vous des applications qui en demandent trop. En tant que constructeur, ne commandez que le nécessaire, c'est la sécurité et le respect des données de l'utilisateur, ce que la LGPD renforce.

Réflexion : le pouvoir avec la responsabilité

OAuth résout un problème réel et élégant, mais concentre les risques. Le jeton est une clé ; s'il fuit, il donne accès à ce qu'il autorise. C’est pourquoi la mise en œuvre compte autant que le concept.

Les jetons doivent voyager en toute sécurité, avoir une courte validité, être révoqués et conservés soigneusement. La spécification a évolué, les bonnes pratiques actuelles préconisent des flux plus sûrs et découragent les anciennes normes. Mettre en œuvre OAuth « copier depuis Internet » sans comprendre ces nuances revient à installer une serrure coûteuse et à laisser la clé sous le tapis. Il vaut la peine de s'appuyer sur des bibliothèques matures et des fournisseurs établis plutôt que de réinventer le protocole.

Clôture

OAuth n'est pas "le moyen de se connecter". C'est le moyen de déléguer l'accès sans remettre les clés de tout. Comprendre cette distinction, l'autorisation, pas l'authentification; C’est un jeton à portée limitée, et non un mot de passe partagé, qui transforme l’utilisation mécanique en une utilisation consciente.

La sécurité ne consiste pas à mémoriser des protocoles. Il s’agit de comprendre ce que chaque pièce protège et ce qu’elle ne protège pas. Ceux qui maîtrisent le concept de OAuth prennent de meilleures décisions, demandent moins de ce dont ils n'ont pas besoin et se méfient au bon moment.

Si vous implémentez une connexion sociale ou une intégration inter-systèmes, il vaut la peine de comprendre le protocole avant de le configurer. J'ai d'autres textes sur le blog sur la sécurité, l'authentification et la protection des données, et, si vous voulez discuter d'une architecture d'accès concrète, c'est le genre de conversation qui fonctionne.