Qu'est-ce qu'OAuth 2.0 ? 

OAuth 2.0, ou « Open Authorization« , est un protocole conçu en 2012 pour permettre à une application d'accéder à certaines de vos données sur un autre service sans avoir besoin de partager votre mot de passe. Imaginez que vous remettiez une clé temporaire à un ami pour qu'il puisse entrer dans votre maison et récupérer un objet précis, sans lui donner accès à tout votre domicile. Cela offre un moyen sûr et pratique de partager des informations tout en protégeant vos identifiants. 

Pourquoi OAuth 2.0 est-il nécessaire ?

Avant 2012, lorsque vous vouliez qu'une application accède à vos données, vous deviez lui donner votre nom d'utilisateur et votre mot de passe. Cela posait plusieurs problèmes : 

• Il était difficile de garantir que l'application utilisait vos informations de manière responsable. 

• Une fois qu'une application avait vos identifiants, elle pouvait potentiellement accéder à toutes vos données, même celles que vous n'aviez pas envie de partager. 

Ce problème est devenu encore plus préoccupant avec l'apparition des applications monopages (Single Page Applications – SPA), qui stockaient souvent vos identifiants pour faciliter l'utilisation, ce qui les rendait plus vulnérables aux attaques. 

Pour résoudre ces problèmes, OAuth 2.0 a été introduit en 2012 pour remplacer OAuth 1.0. Ce protocole permet aux applications d'accéder à vos données de manière sécurisée, avec votre consentement explicite, sans avoir besoin de votre mot de passe. En plus, vous pouvez limiter ce que l'application peut faire, ce qui augmente la sécurité. 

Qui sont les acteurs dans OAuth 2.0 ?

Pour bien comprendre comment OAuth 2.0 fonctionne, il faut connaître les différents acteurs impliqués : 

Resource Owner

Le « propriétaire des ressources » est généralement l'utilisateur, c'est-à-dire vous. Vous êtes celui qui possède les données ou les ressources que l'application souhaite utiliser. 

Resource Server 

Le « serveur de ressources » est l'endroit où vos données sont stockées. C'est ce serveur qui donnera accès aux données demandées, mais uniquement si une autorisation valide est présentée. 

Client (ou Agent)

Le « client » est l'application qui demande l'accès aux ressources. Ce peut être une application mobile, un site web ou tout autre service en ligne. 

Authorization Server

Le « serveur d'autorisation » est le gardien qui vérifie si le client a bien la permission d'accéder aux données demandées. Il délivre un « jeton d'accès » si tout est en ordre. 

Comment fonctionne OAuth 2.0 ? 

Pour bien comprendre OAuth 2.0, il est important de distinguer deux concepts : 

• L'authentification : C'est le processus de vérification de votre identité. Par exemple, vous entrez votre mot de passe ou utilisez votre empreinte digitale pour prouver que c'est bien vous qui accédez à l'application. 

• L'autorisation : Une fois authentifié, l'autorisation définit ce que vous pouvez faire. Par exemple, vous pouvez lire vos messages, mais peut-être pas modifier tous les paramètres de l'application. 

Dans le contexte d'OAuth 2.0, voici comment cela fonctionne avec une application qui veut accéder à vos photos sur Google : 

1. Demande d'autorisation : L'application vous redirige vers Google, où vous vous connectez et donnez votre autorisation pour qu'elle accède à vos photos. C'est ici que vous interagissez pour donner votre consentement. 

1. Obtention d'un jeton d'accès : Une fois que vous avez donné votre autorisation, Google envoie un « jeton d'accès » à l'application. Ce jeton fonctionne comme une clé qui permet à l'application d'accéder à vos photos, sans avoir besoin de votre mot de passe à chaque fois. 

Grâce à ce processus, vos données sont protégées, et l'application n'a accès qu'à ce que vous avez autorisé. Si le jeton d'accès expire, l'application peut utiliser un jeton de rafraîchissement pour obtenir un nouveau jeton, sans que vous ayez à redonner votre autorisation, rendant l'expérience plus fluide. 

Clients Privés vs Clients Publics 

Dans OAuth 2.0, il est important de comprendre qu'il existe deux types de clients :  

1. Clients privés : Ce sont des applications ou des systèmes qui peuvent bien protéger leurs informations sensibles, comme leurs mots de passe ou les secrets qu'ils utilisent pour se connecter à des services. Ces clients fonctionnent dans des environnements sécurisés, comme des serveurs, où il est plus facile de garantir la sécurité. Par exemple, un serveur backend ou une application qui tourne uniquement sur des machines contrôlées par une entreprise. 
2. Clients publics : À l'inverse, ces clients, comme les applications web ou JavaScript qui s'exécutent dans le navigateur, ne peuvent pas bien protéger leurs informations sensibles. Comme ces applications sont souvent utilisées directement par des utilisateurs, elles sont plus exposées aux risques de sécurité. Pour ces clients, il est donc nécessaire d'utiliser des méthodes de sécurité supplémentaires, comme des flux d'autorisation spécifiques ou des stratégies pour renouveler les jetons d'accès afin de limiter les risques. 

Les différents flux d'autorisation

Selon le type de client (privé ou public), OAuth 2.0 propose différents flux d'autorisation qui déterminent comment une application obtient un jeton d'accès.  

Ces flux (ou « flow » en anglais) sont conçus pour permettre à une application d'accéder aux ressources d'un utilisateur sans que celui-ci ait à partager son mot de passe. Ce processus en plusieurs étapes garantit la sécurité des informations tout en offrant à l'utilisateur le contrôle sur les permissions accordées à chaque application.  

Voici les principaux flux d'autorisation : 

Code d’Autorisation

Le Code d’Autorisation est le flux le plus sécurisé, surtout pour les clients privés. L’utilisateur est redirigé vers un serveur d’autorisation, où il se connecte et donne son consentement. Un code est ensuite envoyé à l’application, qui l’échange contre un jeton d’accès. Ce flux est recommandé car il protège mieux les informations sensibles. 

Flux Implicite

Le Flux Implicite est souvent utilisé pour les clients publics, comme les applications web simples. L’application obtient directement un jeton d’accès après que l’utilisateur a donné son autorisation. Ce flux est moins sécurisé, car le jeton est directement exposé dans le navigateur.

Identifiants du Propriétaire de la Ressource

Ce flux utilise directement les identifiants (nom d'utilisateur et mot de passe) de l'utilisateur pour obtenir un jeton d'accès. Il est utilisé lorsque l'application a une relation de confiance élevée avec l'utilisateur, par exemple dans le cas d'une application intégrée au système d'exploitation. 

Client Credentials

Dans ce flux, l’application agit en son propre nom pour obtenir un jeton d’accès, sans intervention de l’utilisateur. Cela se produit souvent lorsque des services internes ou des API ont besoin d’accéder à des ressources sans l’utilisateur.

Hybrid Flow 

Le Flux Hybride combine les avantages du flux implicite et du code d’autorisation. Il permet un accès immédiat aux données tout en offrant une validation d’identité plus rigoureuse. Ce flux est complexe mais utile dans des situations où la sécurité et l’accès rapide sont nécessaires. Pour plus de détails se référer OIDC specification (Open ID Connect). 

Pour conclure…

OAuth 2.0 est un protocole essentiel pour sécuriser les applications et les API. Il permet de contrôler l’accès aux données en fonction des besoins spécifiques de chaque service, tout en assurant une sécurité renforcée grâce à des mécanismes comme les tokens Bearer. 

Son points forts est sa capacité à s’adapter à différents systèmes, que ce soit pour des applications web, mobiles ou cloud. Son adoption large et continue en fait un choix fiable, avec une compatibilité assurée grâce à son statut de norme ouverte. 

Cependant, pour qu’il soit vraiment efficace, il est crucial de bien l’implémenter. Une mauvaise configuration peut créer des failles de sécurité. Par exemple, une gestion incorrecte des tokens de rafraîchissement peut exposer les données utilisateur. Il est donc essentiel de sécuriser correctement les secrets clients et de suivre les bonnes pratiques de gestion des tokens. 

Pour bien utiliser ce Framework, il est recommandé d’opter pour des bibliothèques reconnues et de rester à jour avec les dernières pratiques de sécurité. Une attention particulière doit être portée aux erreurs courantes, comme la gestion des flux d’autorisation dans les applications publiques. 

Un projet d’exemple est disponible, ici, pour illustrer les bonnes pratiques et faciliter l’implémentation de ce protocole.