Des choses importantes que vous devez savoir sur OAuth

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

L'idée est de permettre aux applications client un accès limité aux informations de l'utilisateur sans jamais partager des informations d'identification ou un mot de passe. OAuth Framework est responsable des échanges requis avant qu'une demande n'obtient vos informations.

Supposons que vous souhaitiez vous inscrire à Dev.à (ce qui est un excellent endroit pour les développeurs pour échanger des idées), ils vous permettent de vous inscrire en utilisant votre compte GitHub. Comment cela se passe-t-il? Comment sauraient-ils que vous possédez le compte GitHub, que vous vous inscrivez avec?

Plus important encore, comment vous assurez-vous que Dev.ne pas dépasser 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 le code à GitHub directement en utilisant l'interface atoM. La raison à cela comme exemple est que Github ne cache pas les détails derrière la scène et vous pouvez voir ce qui se passe sous le capot.

Avant de monter dans les minuties du travail d'Oauth. Jetons le terrain 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 accessibles (lire et / ou écrire) afin de le faire fonctionner avec une application.
2. Client: Ceci est l'application qui cherche votre autorisation pour accéder à vos informations à partir d'un autre service. Dans notre exemple, ATOM Editor est le client.
3. Ressource: La ressource est vos informations réelles dans les serveurs dans un endroit éloigné. Ceci peut être accessible via une API si le client obtient des autorisations appropriées.
4. Serveur d'autorisation: Interfacé également avec une API. Ce serveur est maintenu par le fournisseur de services (GitHub dans notre exemple). Le serveur d'autorisation et le serveur de ressources sont appelés API car ils sont gérés par une entité, dans ce cas GitHub, et exposés en API au développeur client.

Enregistrement OAuth

Le processus démarre lorsque l'application client est en cours d'élaboration. Vous pouvez vous rendre au fournisseur de ressources et vous inscrire avec le portail de leur développeur ou la section API du site Web. Vous devrez également fournir une URL de rappel où l'utilisateur serait redirigé après avoir accepté ou rejeté pour donner l'application nécessaire aux autorisations nécessaires.

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

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

OAuth 2 Workflow

Vous avez enregistré votre demande. Il a été développé et testé et maintenant les utilisateurs sont prêts à l'utiliser. Un nouvel utilisateur lors de l'inscription auprès de votre service serait affiché l'option de «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 sur la page Web des ressources et demande aux utilisateurs de se connecter. Si vous êtes déjà connecté, sur cet appareil, cette étape est ignorée et vous êtes simplement demandé par GitHub si vous souhaitez donner accès à l'application client Atom. C'est beaucoup plus transparent dans le cas d'atome 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.

Remarquez l'URL qui montre 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 hors de route.

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

Étape 2: Obtenir la subvention d'autorisation

Pour informer le client Atom, vous recevez un jeton (une subvention d'autorisation) qui est ensuite soumis au client atomique.

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 la subvention d'échange 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

La subvention d'autorisation n'est toujours pas l'entité qui donne au client l'accès aux informations de l'utilisateur. Qui est obtenu en utilisant quelque chose appelé un jeton d'accès. Que l'application client essaiera d'atteindre cette étape.

Pour ce faire, le client devra désormais fournir la subvention d'autorisation au serveur d'autorisation ainsi qu'une preuve de sa propre identité. L'identité est vérifiée en utilisant l'ID client et le secret du client qui ont été donnés à l'application client plus tôt.

La vérification de l'identité est effectuée pour s'assurer que l'utilisateur n'est pas trompé dans l'utilisation d'une application néfaste qui fait semblant d'être une application légitime. Par exemple, si quelqu'un décide de nommer son exécutable en tant qu'atome avec le même nom, le logo et la fonctionnalité L'utilisateur peut se faire tromper pour donner accès à un client qui peut abuser de vos informations. Ils peuvent espionner ou même agir sans votre consentement. Le serveur d'autorisation garantit que le client est en effet ce qu'il apparaît à ses utilisateurs.

Une fois l'identité vérifiée et que la subvention d'autorisation est acceptée, le serveur d'autorisation jette un jeton à l'application client. Considérez le jeton comme une combinaison du nom d'utilisateur et du mot de passe qui peut être donné au serveur de ressources pour accéder à une ressource protégée particulière que 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 autres ressources du serveur de ressources.

Remarquez comment, dans tout cet échange, le nom d'utilisateur et le mot de passe réels où ne partagent jamais avec le client? C'est la beauté de OAuth. Au lieu de donner un nom d'utilisateur et des mots de passe qui accordent à l'application tout l'accès à la ressource, il utilise plutôt des jetons. Et un jeton ne peut gagner qu'un accès limité à la ressource.

Révoquer les autorisations

Supposons que vous perdiez l'accès à votre appareil qui avait l'application client autorisée. Vous pouvez vous connecter à GitHub et accéder aux paramètres → Applications → Applications OAuth autorisées pour révoquer la subvention 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'oiseau de la façon dont Oauth 2.Vous pouvez en savoir plus sur les subventions d'autorisation et autres détails plus fins du protocole et comment les appels API sont passés ici.