Ce que vous devez savoir sur OAuth

OAuth est quelque chose que chaque développeur doit savoir. Si vous créez une application autonome ou une application tierce qui s'intègre à un autre service HTTP, vous devez savoir comment fonctionne OAuth pour fournir à vos utilisateurs un service facile à utiliser et bien intégré.

L'idée est de permettre aux applications clientes un accès limité aux informations utilisateur sans jamais partager les informations d'identification ou le mot de passe de l'utilisateur. Le framework OAuth est responsable des échanges nécessaires avant qu'une application n'obtienne vos informations.

Supposons que vous vouliez vous inscrire à Dev.à (ce qui est un endroit idéal pour les développeurs d'échanger des idées), ils vous permettent de vous inscrire en utilisant votre compte GitHub. Comment ça se passe? Comment sauraient-ils que vous possédez le compte GitHub avec lequel vous vous inscrivez ??

Plus important encore, comment vous assurez-vous que Dev.ne dépasse pas ses limites en ce qui concerne vos informations stockées avec GitHub?

Participants OAuth

Nous nous en tiendrons à l'exemple du plugin GitHub de l'éditeur Atom qui permet aux développeurs de pousser du code vers GitHub directement en utilisant l'interface Atom. La raison de cet exemple est que GitHub ne cache pas les détails derrière la scène et vous permet de voir ce qui se passe sous le capot.

Avant d'entrer dans les détails du travail d'OAuth. Plantons le décor en reconnaissant tous les participants à l'échange :

1. Propriétaire ou utilisateur de la ressource : Cet utilisateur est celui dont les informations de compte doivent être consultées (lecture et/ou écriture) afin de les faire fonctionner avec une application.
2. Client: Il s'agit de l'application qui sollicite votre autorisation pour accéder à vos informations à partir d'un autre service. Dans notre exemple, l'éditeur Atom est le client.
3. Ressource: La ressource est votre information réelle se trouvant dans les serveurs dans un endroit distant. Ceci est accessible via une API si le client dispose des autorisations appropriées.
4. Serveur d'autorisation: Egalement interfacé via une API. Ce serveur est maintenu par le fournisseur de service (GitHub dans notre exemple). Le serveur d'autorisation et le serveur de ressources sont tous deux appelés API car ils sont gérés par une entité, dans ce cas GitHub, et exposés en tant qu'API au développeur client.

Enregistrement OAuth

Le processus démarre lorsque l'application Client est en cours de développement. Vous pouvez vous rendre chez le fournisseur de ressources et vous inscrire sur le portail de leur développeur ou sur la section API du site Web. Vous devrez également fournir une URL de rappel où l'utilisateur serait redirigé après avoir accepté ou refusé pour donner à l'application les autorisations nécessaires.

Par exemple, si vous allez dans GitHub → Paramètres → Paramètres du développeur et cliquez sur « Enregistrer une nouvelle demande ». Cela vous fournirait un identité du client qui peut être rendu public et un Secret du client qui, l'organisation de développeur doit garder… bien un secret.

Une fois que l'ID client et le secret vous ont été fournis, le développeur, vous doit gardez-les en sécurité car ils ne seront plus affichés par le serveur d'autorisation. Il en va de même pour tous les autres jetons qui seraient jetés (Plus sur les jetons plus tard).

Flux de travail OAuth 2

Vous avez enregistré votre candidature. Il a été développé et testé et maintenant les utilisateurs sont prêts à l'utiliser. Un nouvel utilisateur lors de l'inscription à votre service se verra proposer l'option « Se connecter avec GitHub ». C'est le premier pas.

Étape 1 : Demande d'autorisation

La demande d'autorisation est la partie où une nouvelle fenêtre (ou une invite similaire) s'ouvre avec la page Web de la ressource et demande aux utilisateurs de se connecter. Si vous êtes déjà connecté sur cet appareil, cette étape est ignorée et GitHub vous demande simplement si vous souhaitez donner accès à l'application cliente Atom. C'est beaucoup plus transparent dans le cas d'Atom car ils vous demandent d'aller manuellement sur le site Web de GitHub et de leur accorder l'autorisation.

En visitant l'URL, on vous demande l'autorisation.

Notez l'URL qui indique qu'il s'agit d'une page Web sécurisée (HTTPS) par GitHub.Inc. Maintenant, vous, l'utilisateur, pouvez être certain que vous interagissez directement avec GitHub. Atom attend simplement, assez à l'écart.

Contrairement à Atom, la plupart des applications clientes chargent automatiquement la page de connexion ou d'autorisations. Bien que cela soit très pratique, cela peut également être utilisé à mauvais escient, si l'application cliente décide d'ouvrir un lien de phishing. Pour éviter cela, vous devez toujours vérifier l'URL vers laquelle vous êtes redirigé et vous assurer qu'il s'agit d'une URL correcte et qu'elle utilise le protocole HTTPS.

Étape 2 : Obtention de la subvention d'autorisation

Pour notifier le client Atom, vous recevez un jeton (un octroi d'autorisation) qui est ensuite soumis au client Atom.

Une fois que l'utilisateur fait cela, le travail de l'utilisateur est terminé. (En fait, un utilisateur typique n'est même pas au courant de l'échange de l'octroi d'autorisation. L'exemple de GitHub a été choisi pour montrer que c'est ce qui se passe).

Étape 3 : Obtenir le jeton d'accès

L'octroi de l'autorisation n'est toujours pas l'entité qui donne au client l'accès aux informations de l'utilisateur. Cela est obtenu en utilisant quelque chose appelé un jeton d'accès. Ce que l'application client essaiera d'obtenir dans cette étape.

Pour ce faire, le client devra maintenant fournir l'octroi d'autorisation au serveur d'autorisation accompagné d'une preuve de sa propre identité. L'identité est vérifiée à l'aide de l'ID client et du secret client qui ont été précédemment fournis à l'application client.

La vérification d'identité est effectuée pour s'assurer que l'utilisateur n'est pas trompé en utilisant une application néfaste qui prétend être une application légitime. Par exemple, si quelqu'un décide de nommer son exécutable Atom avec le même nom, l'utilisateur du logo et de la fonctionnalité peut être amené à donner accès à un client qui peut abuser de vos informations. Ils peuvent fouiner ou même agir sans votre consentement. Le serveur d'autorisation s'assure que le client est bien ce qu'il apparaît à ses utilisateurs.

Une fois l'identité vérifiée et l'octroi de l'autorisation accepté, le serveur d'autorisation envoie un jeton à l'application cliente. Considérez le jeton comme une combinaison de nom d'utilisateur et de mot de passe qui peut être donné au serveur de ressources pour accéder à une ressource protégée particulière à laquelle le propriétaire de la ressource vous a permis d'accéder.

Enfin, en utilisant ce jeton, l'application peut désormais accéder aux informations utilisateur requises et à d'autres ressources à partir du serveur de ressources.

Remarquez comment, dans tout cet échange, le nom d'utilisateur et le mot de passe réels n'ont jamais été partagés avec le client? C'est la beauté d'OAuth. Au lieu de donner un nom d'utilisateur et des mots de passe qui accorderaient à l'application tout l'accès à la ressource, elle utilise des jetons à la place. Et un jeton ne peut obtenir qu'un accès limité à la ressource.

Révocation des autorisations

Supposons que vous perdiez l'accès à votre appareil qui contenait l'application cliente autorisée. Vous pouvez vous connecter à GitHub et accéder à Paramètres → Applications → Applications OAuth autorisées pour révoquer l'octroi d'autorisation et le jeton d'accès. Je ferai de même, car, dans les captures d'écran ci-dessus, la subvention d'autorisation a été affichée publiquement.

Maintenant que vous avez une vue d'ensemble de la façon dont OAuth 2.Vous pouvez en savoir plus sur les autorisations accordées et d'autres détails plus précis du protocole et sur la façon dont les appels d'API sont effectués ici.