Dans cet article, je passerai en revue les bases de l’utilisation d’OAuth 2.0, et vous montrerai étape par étape comment obtenir un jeton d’accès OAuth. Il sera question de fournir ici une présentation du protocole OAuth 2.0 en discutant des différents acteurs et étapes impliquées dans le processus de mise en œuvre de ce protocole.

 

 

 

 

Introduction:

OAuth est l’acronyme de Open Authorization. C’est un protocole libre et ouvert, basé sur les normes IETF et les licences de l’Open Web Foundation. Il permet aux utilisateurs de partager leurs ressources privées avec un tiers tout en gardant leurs propres informations d’identification secrètes. Ces ressources peuvent être des photos, des vidéos, des listes de contacts, des capacités de localisation et de facturation, etc., et sont généralement stockées grâce à un autre fournisseur de services. OAuth le fait en accordant un jeton aux applications demandeuses (clientes), une fois l’accès approuvé par l’utilisateur. Chaque jeton accorde un accès limité à une ressource spécifique pour une période spécifique.

1. Oauth2 est un protocole de délégation:

OAuth2 prend en charge l’authentification déléguée, c’est-à-dire l’accès à une autre personne ou application pour effectuer des actions en votre nom. Considérez ce scénario: vous conduisez votre voiture à un hôtel chic, ils peuvent offrir un service de voiturier. Vous autorisez alors le voiturier à conduire votre voiture en lui remettant la clé afin de le laisser effectuer des actions en votre nom.

OAuth2 fonctionne de manière similaire: un utilisateur accorde l’accès à une application pour effectuer des actions limitées au nom de l’utilisateur et l’accès peut être révoqué lorsqu’il devient suspect.

2. Acteurs impliqués dans OAuth2:

i) Serveur de ressources: serveur hébergeant des ressources appartenant à l’utilisateur et protégées par OAuth2. Le serveur de ressources valide le jeton d’accès et fournit les ressources protégées.

ii) Propriétaire de la ressource: En règle générale, l’utilisateur de l’application est le propriétaire de la ressource. Le propriétaire de la ressource a la possibilité d’accorder ou de refuser l’accès à ses propres données hébergées sur le serveur de ressources.

iii) Serveur d’autorisation: le serveur d’autorisation obtient le consentement du propriétaire de la ressource et émet des jetons d’accès aux clients pour accéder aux ressources protégées hébergées par un serveur de ressources.

iv) Client: Une application faisant des demandes d’API pour effectuer des actions sur des ressources protégées au nom du propriétaire de la ressource. Avant de pouvoir le faire, il doit être autorisé par le propriétaire de la ressource et l’autorisation doit être validée par le serveur de ressources/le serveur d’autorisation. OAuth2 définit deux types de clients, en fonction de leur capacité à s’authentifier en toute sécurité avec le serveur d’autorisation (c’est-à-dire, la capacité à maintenir la confidentialité de leurs informations d’identification client):

• Confidentiel: Clients capables de préserver la confidentialité de leurs informations d’identification. Les clients confidentiels sont implémentés sur un serveur sécurisé avec un accès restreint aux informations d’identification du client (par exemple, une application Web s’exécutant sur un serveur Web).
• Public: Clients incapables de préserver la confidentialité de leurs informations d’identification (par exemple, une application native installée ou une application basée sur un navigateur Web) et incapables de sécuriser l’authentification du client par d’autres moyens.

3. Vous êtes un développeur d’applications, voici un cas d’utilisation:

Considérons un scénario. Vous développez une application Facebook amusante, et vous l’appelez « FunApp ». FunApp doit avoir accès au profil public de l’utilisateur, photos, messages, amis, etc. Maintenant, le problème est de savoir comment FunApp peut obtenir l’autorisation de l’utilisateur pour accéder à ses données depuis Facebook, tout en informant Facebook que l’utilisateur a donné l’autorisation à cette application d’accéder à son profil.

L’ancienne façon: l’utilisateur partage ses informations d’identification facebook (nom d’utilisateur, mot de passe) avec FunApp. Cette approche a quelques défis: la confiance, l’accès illimité, les modifications du mot de passe Facebook faites par l’utilisateur, etc.

La méthode OAuth2: Funapp redirigeait les utilisateurs vers une page d’autorisation sur Facebook si l’application avait besoin d’accéder à leurs données utilisateur. Les utilisateurs se connecteraient à leurs comptes et accorderaient l’accès, puis FunApp obtiendrait un jeton d’accès de Facebook pour accéder aux données de l’utilisateur. Alors qu’Oauth2 a résolu ces problèmes, cela a également engendré des coûts pour les développeurs.

Voyons ce scénario dans les yeux du développeur et découvrons les acteurs impliqués ici:

•     Puisque Facebook dispose de toutes les ressources (profil public de l’utilisateur, photos, posts, amis, etc.), il devient le serveur de ressources.
•     L’utilisateur est le propriétaire de la ressource.
•     Lorsque FunApp demande les ressources protégées de l’utilisateur, il devient le client.
•     Lorsque Facebook obtient le consentement de l’utilisateur et émet le jeton d’accès à FunApp, il devient le serveur d’autorisation.

4. Enregistrez le client (FunApp) et obtenez les informations d’identification du client:

OAuth requiert que le client s’enregistre auprès du serveur d’autorisation. Le serveur d’autorisation demande des informations de base sur le client telles que name, redirect_uri (l’URL vers laquelle le serveur d’autorisation redirigera lorsque le propriétaire de la ressource accorde l’autorisation) et renvoie les informations d’identification client (client-id, client-secret) au client. Ces informations d’identification sont essentielles pour protéger l’authenticité des demandes lors de l’exécution d’opérations telles que l’échange de codes d’autorisation pour les jetons d’accès et l’actualisation des jetons d’accès.

Par exemple, Facebook vous oblige à enregistrer votre client sur le portail Facebook Developers. Allez sur le portail des développeurs Facebook et enregistrez FunApp et obtenez les informations d’identification du client.

5. Obtenez un jeton d’accès pas à pas:

FunApp doit obtenir un jeton d’accès de Facebook pour accéder aux données de l’utilisateur. Afin d’obtenir un jeton d’accès, FunApp redirige l’utilisateur vers la page de connexion de Facebook. Une fois la connexion établie, Facebook redirige vers la redirection_uri (enregistrée à l’étape 4) avec le code d’autorisation de courte durée. FunApp échange le code d’autorisation pour obtenir le jeton d’accès de longue durée. Le jeton d’accès est utilisé pour accéder aux données de l’utilisateur. C’est le flux le plus populaire dans OAuth2. Voici le diagramme de séquence pour obtenir un jeton d’accès dans l’attribution de code d’autorisation.

6. Comprendre les types d’autorisation accordées:

Pour obtenir le jeton d’accès, le client obtient l’autorisation du propriétaire de la ressource. OAuth2 définit quatre types d’autorisation standard: code d’autorisation, implicite, informations d’identification du mot de passe du propriétaire de la ressource et informations d’identification du client. Il fournit également un mécanisme d’extension pour définir des types d’autorisation supplémentaires.

•  Code d’autorisation: ce type d’autorisation est optimisé pour les clients confidentiels (serveur d’applications Web). Le flux de code d’autorisation n’expose pas le jeton d’accès au navigateur du propriétaire de la ressource. Au lieu de cela, l’autorisation est accomplie en utilisant un « code d’autorisation » intermédiaire qui est passé par le navigateur. Ce code doit être échangé contre un jeton d’accès avant que des appels puissent être passés aux API protégées.
• Autorisation implicite: ce type d’autorisation convient aux clients publics. Le flux d’allocation implicite n’accueille pas les jetons d’actualisation. Si le serveur d’autorisations expire régulièrement des jetons d’accès, votre application devra parcourir le flux d’autorisations chaque fois qu’il aura besoin d’y accéder. Dans ce flux, un jeton d’accès est immédiatement renvoyé au client après qu’un utilisateur ait accordé l’autorisation demandée. Un code d’autorisation intermédiaire n’est pas requis car il figure dans le code d’autorisation.
• Informations d’identification du mot de passe du propriétaire de ressource: le type de licence d’identification du mot de passe du propriétaire de la ressource est approprié si le propriétaire de la ressource a une relation d’approbation avec le client. Ensuite, le client peut utiliser les ressources des informations d’identification du propriétaire pour obtenir le jeton d’accès du serveur d’autorisation.
• Informations d’identification du client: ce type de subvention convient lorsque le client possède les données et n’a pas besoin d’un accès délégué d’un propriétaire de ressource, ou qu’un accès délégué a déjà été accordé à l’application en dehors d’un flux OAuth standard. Dans ce flux, le consentement de l’utilisateur n’est pas impliqué. Le client échange ses informations d’identification client pour obtenir un jeton d’accès.

7. Jeton expiré, obtenez un nouveau jeton d’accès:

La création d’appels API à l’aide du jeton d’accès OAuth 2.0 peut rencontrer des erreurs si le jeton d’accès n’est plus valide car le jeton a expiré ou a été révoqué. Dans ce cas, le serveur de ressources renverra un code d’erreur 4xx. Le client peut obtenir le nouveau jeton d’accès en utilisant le jeton d’actualisation (qui a été obtenu lorsque le code d’autorisation a été échangé contre un jeton d’accès).

8. Conclusion:

Ceci est une tentative de fournir une vue d’ensemble du processus OAuth 2.0, ainsi que de fournir un moyen d’obtenir un jeton d’accès. J’espère que cela a été utile.

Amusez-vous à intégrer des applications!