Premiers pas avec OAuth 2.0

OAuth ne partage pas les données de mot de passe mais utilise à la place des jetons d'autorisation pour prouver une identité entre les consommateurs et les fournisseurs de services. Regardons de plus près.

L'explosion du Web nous a offert la possibilité d'utiliser différentes applications ou services pour effectuer notre travail, ce qui signifiait également que nous devions stocker et gérer nos ressources par application. Ainsi, la décentralisation des ressources a apporté l'avantage de séparer les préoccupations des utilisateurs et leurs données, mais elle a également introduit de nouvelles failles.

Comment les ressources d'un utilisateur stockées sur différentes applications peuvent-elles être partagées par ces applications pour effectuer des tâches pour l'utilisateur ? La réponse à cette question est ce qui a rendu le protocole OAuth (Open Authorization) suffisant.

L'OAuth (dernière version 2.0) dicte les normes requises des services disparates, des applications Web ou des sites Web pour s'autoriser à accéder aux ressources au nom d'un utilisateur .

Regardons d'abord une solution imparfaite à ce problème pour comprendre clairement ce qu'OAuth apporte à la table et voir comment il gère l'autorisation, ainsi que les problèmes de sécurité pour ces applications qui ont besoin d'accéder à une ressource protégée.

Le Solution défectueuse

Le moyen le plus simple de permettre à une application tierce (client) d'accéder à ses ressources à partir d'une autre application consiste à lui fournir des identifiants de connexion (nom d'utilisateur et mot de passe). Bien qu'il s'agisse du flux le plus intuitif, il présente les inconvénients suivants :

• Si l'application tierce est compromise, piratée ou devient malveillante, les ressources de l'utilisateur deviennent vulnérables.
• L'entité ne peut pas modérer ce qu'elle veut du tiers. application tierce à accéder, c'est-à-dire que l'application tierce a des privilèges pour accéder à toutes les ressources.
• L'entité peut autoriser plusieurs applications à accéder à ses ressources. Si l'entité souhaite révoquer l'accès à une application, elle doit modifier ses identifiants de connexion et donner les nouveaux identifiants pour autoriser les applications, ce qui est fastidieux.
• Bien que cette solution soit théoriquement possible, elle n'est pas pratique car la plupart des utilisateurs ne peuvent pas confier leurs identifiants de connexion à une application tierce aléatoire.

Ce que fournit OAuth

Pour bien comprendre ce que fournit OAuth et comment il résout les problèmes ci-dessus, commençons par comprendre certains termes fréquemment utilisés dans l'espace OAuth.

• Ressource : quelque chose qui est recherché, par exemple des photos, des vidéos, des informations personnelles.
• Propriétaire de la ressource : une entité qui possède certaines ressources stockées sur un serveur de ressources et peut autoriser une autre application d'accéder à ces ressources protégées en son nom. Une entité peut être une personne (utilisateur final), un programme ou un service.
• Client : toute application tierce qui a besoin d'accéder aux ressources d'une entité. Un client peut être un serveur Web, une application d'une seule page, une application mobile ou une application de bureau.
• Jeton d'accès : Jeton délivré au client par le serveur d'autorisation pour accéder à la ressource d'une entité sur le serveur de ressources .
• Serveur de ressources : un serveur sur lequel les ressources protégées de l'utilisateur sont conservées et gérées, par exemple, Google Drive, Dropbox, YouTube. Les ressources stockées ici ne sont accessibles qu'en fournissant un jeton d'accès valide.
• Serveur d'autorisation : un serveur qui émet des jetons d'autorisation et des jetons d'accès à un client pour accéder à une ressource à partir d'un serveur de ressources.[19659009]URI de redirection : un URI enregistré et sécurisé (c'est-à-dire un URI exécutant HTTPS), que le serveur d'autorisation utilise pour fournir au client le code d'autorisation après avoir authentifié le propriétaire de la ressource.

Remarque : Le serveur de ressources et le serveur d'autorisation peuvent tous deux s'exécuter sur le même serveur.

Désormais, dans le protocole OAuth, les identifiants de connexion ne sont pas transmis directement au client. Au lieu de cela, le client (application tierce) reçoit un jeton d'accès, qui est ensuite utilisé pour accéder au serveur de ressources afin d'obtenir la ressource ; c'est le flux en un coup d'œil. Voyons ensuite comment cela est réalisé.

Flux OAuth

Le schéma ci-dessous montre la séquence d'événements qui se produisent pour autoriser un client (application tierce) à accéder à une ressource à partir d'un service mettant en œuvre OAuth pour le compte de un utilisateur.

Regardons maintenant les activités impliquées dans chaque étape.

Les étapes 1 et 2 impliquent que le propriétaire de la ressource (utilisateur) autorise le client à accéder à son Ressources. L'utilisateur, dans la plupart des cas, n'autorise l'accès qu'à des parties spécifiques de sa ressource. Cette limitation de l'accès du client est appelée la portée. L'utilisateur peut accorder une ou plusieurs portées au client.

À l'étape 3, le client, en fonction de cette portée, fait maintenant une autre demande indiquant au serveur d'autorisation qu'il souhaite accéder à une ressource au nom d'un propriétaire de ressource.[19659003]Avant que le client puisse faire une requête au serveur d'autorisation, le propriétaire de l'application cliente (développeur) doit enregistrer l'application sur le service implémentant le serveur d'autorisation, généralement en remplissant un formulaire HTML avec des informations sur l'application telles que son type, nom de domaine, URI de redirection, etc.

À des fins de démonstration, vous trouverez ci-dessous un exemple de diagramme illustrant comment une application cliente peut être enregistrée pour Google OAuth. Cependant, cela peut être fait sur tout autre service utilisant OAuth, comme GitHub, Facebook ou Twitter.

{ id_client :"942821610187-h9d951h3l8f3gfgoqdee8v06oehl.apps.oauthservice.com", client_secret :"SflKxwRJSMeKKF2QT4fwpMeJf3" }

Le protocole OAuth spécifie différents types de clients et émet un secret client en fonction du type. Les secrets client sont délivrés aux clients confidentiels (clients qui s'exécutent dans un environnement sécurisé et peuvent garder le secret en sécurité), comme une application Web exécutée sur un serveur Web sécurisé. En revanche, les clients publics (clients qui ne peuvent pas garder leur secret confidentiel), tels que les applications mobiles ou un SPA exécuté dans le navigateur, ne reçoivent pas de secret. Il est essentiel de noter que le type de client détermine le flux OAuth.

A l'étape 4, le serveur d'autorisation a reçu une requête du client. Il tente ensuite d'authentifier le propriétaire de la ressource via une connexion et demande le consentement que le client souhaite accéder à un sous-ensemble des ressources de l'utilisateur dicté par la portée, comme indiqué précédemment. Si l'autorisation est accordée, le serveur d'autorisation, selon le type de client, procède comme suit :

• Pour un client public, un jeton d'accès est généré et renvoyé au client à l'aide de l'URI de redirection fourni par le client lorsqu'il a été inscrit. Le client public peut accéder à la ressource à l'étape 7 sans avoir besoin de passer par l'étape 6. Ce type de flux OAuth est appelé flux implicite. La séquence d'événements de cette étape est décrite comme suit.

• Pour les clients confidentiels, le serveur d'autorisation émet un jeton d'autorisation, qui sera utilisé à l'étape 6 pour obtenir le jeton d'accès.

À l'étape 6, le client (client confidentiel) obtient un jeton d'accès à l'aide du jeton serveur de sation, puis utilise ce jeton pour accéder à la ressource de l'utilisateur à l'étape 7. Ce type de flux OAuth est appelé le flux de code d'autorisationqui est le flux préféré et le plus sécurisé par rapport à la variante implicite.[19659003]

Pour les deux types de clients, un jeton d'accès peut être renvoyé avec un jeton d'actualisation afin d'obtenir un nouveau jeton d'accès lorsque le jeton émis expire.

]Enfin, le client utilise ce jeton d'accès pour obtenir la ressource de l'utilisateur auprès du serveur de ressources.

Avantages de l'utilisation d'OAuth

• L'utilisateur n'a pas besoin de partager les identifiants de connexion avec le client.
• Le client est uniquement autorisé à accéder à des parties spécifiques de la ressource d'un utilisateur.
• Les jetons peuvent facilement être révoqués si l'utilisateur annule l'autorisation d'un client sans modifier les informations d'identification de connexion.
• OAuth garantit que les jetons d'accès sont partagés via un canal sécurisé.
• Un utilisateur n'a pas besoin de créer plusieurs comptes sur différentes applications tierces.

Conclusion

OAuth nous donne la possibilité d'autoriser les applications à s'autoriser elles-mêmes ; les problèmes de sécurité doivent rester primordiaux lors de la mise en œuvre dans une application. Espérons que ce guide nous donne une longueur d'avance sur OAuth et nous met en bonne forme pour l'explorer davantage et l'implémenter dans de futurs projets.

Ensuite, vous pouvez apprendre à mettre en œuvre OAuth 2.0 dans Node.js.