Question À un niveau élevé, comment fonctionne OAuth 2?


Si je comprends bien, la chaîne d'événements suivante se produit dans OAuth 2 afin de Site-A accéder Utilisateurs Information provenant de Site-B.

  1. Site-A enregistre sur Site-Bet obtient un secret et une carte d'identité.
  2. Quand Utilisateur raconte Site-A accéder Site-B, Utilisateur est envoyé à Site-B où il dit Site-B qu'il aimerait bien donner Site-A autorisations à des informations spécifiques.
  3. Site-B redirections Utilisateur retour à Site-A, avec un code d'autorisation.
  4. Site-A passe ensuite ce code d'autorisation avec son secret à Site-B en échange d'un jeton de sécurité.
  5. Site-A puis fait des demandes à Site-B de la part de Utilisateur en regroupant le jeton de sécurité avec les demandes.

Comment tout cela fonctionne-t-il en termes de sécurité et de cryptage, à un niveau élevé? Comment OAuth 2 protège-t-il contre des éléments tels que les attaques de rejeu à l'aide du Security Token?


506
2018-01-18 17:44


origine


Réponses:


Comment fonctionne OAuth 2.0 dans la vraie vie:

Je conduisais la boulangerie d'Olaf sur le chemin du travail quand j'ai vu le beignet le plus délicieux de la fenêtre - je veux dire, la chose dégoulinait de chocolat. Alors je suis allé à l'intérieur et j'ai demandé "Je dois avoir ce beignet!". Il a dit "sûr que ce sera 30 $."

Ouais je sais, 30 $ pour un beignet! Ça doit être délicieux! J'ai tendu la main pour mon porte-monnaie quand tout à coup j'ai entendu le chef crier «NON, pas de beignet pour toi». J'ai demandé: pourquoi? Il a dit qu'il n'accepte que les virements bancaires.

Sérieusement? Oui, il était sérieux. Je suis presque parti juste là, mais le beignet m'a appelé: "Mange-moi, je suis délicieux ...". Qui suis-je pour désobéir aux ordres d'un beignet? J'ai dit ok.

Il m'a remis une note avec son nom dessus (le chef, pas le beignet): "Dis-leur que Olaf t'a envoyé". Son nom était déjà inscrit sur la note, donc je ne sais pas à quoi ça voulait dire, mais d'accord.

J'ai conduit une heure et demie à ma banque. J'ai remis la note au caissier; Je lui ai dit Olaf m'a envoyé. Elle m'a donné un de ces regards, le genre qui dit, "je peux lire".

Elle a pris ma note, m'a demandé mon identité, m'a demandé combien d'argent pouvait lui donner. Je lui ai dit 30 dollars. Elle a griffonné et m'a remis une autre note. Celui-ci avait un tas de chiffres dessus, je devinais que c'est comme ça qu'ils gardaient les notes.

À ce moment-là, je meurs de faim. Je suis sorti de là, une heure et demie plus tard, j'étais de retour devant Olaf avec ma note prolongée. Il l'a pris, l'a regardé et a dit: "Je serai de retour".

Je pensais qu'il recevait mon beignet, mais après 30 minutes j'ai commencé à me méfier. Alors j'ai demandé au gars derrière le comptoir "Où est Olaf?". Il a dit "Il est allé chercher de l'argent". "Que voulez-vous dire?". "Il prend note à la banque".

Huh ... alors Olaf a pris la note que la banque m'a donnée et est retournée à la banque pour retirer de l'argent de mon compte. Comme il avait le billet que la banque m'avait donné, la banque savait qu'il était le gars dont je parlais, et parce que j'ai parlé à la banque, ils savaient qu'il ne lui donnerait que 30 dollars.

Il a fallu beaucoup de temps pour que je le comprenne car au moment où j'ai levé les yeux, Olaf se tenait devant moi enfin me tend mon beignet. Avant de partir, je devais demander: "Olaf, avez-vous toujours vendu des beignets de cette façon?". "Non, je le faisais différemment."

Huh. Alors que je revenais à ma voiture, mon téléphone a sonné. Je n'ai pas pris la peine de répondre, c'était probablement mon travail d'appeler à me virer, mon patron est tellement ***. De plus, j'ai été pris en train de penser au processus que je venais de traverser.

Je veux dire, réfléchissez: j'ai pu laisser Olaf retirer 30 dollars de mon compte bancaire sans avoir à lui donner les informations de mon compte. Et je n'avais pas à m'inquiéter de prendre trop d'argent parce que j'avais déjà dit à la banque qu'il ne pouvait prendre que 30 dollars. Et la banque savait qu'il était le bon gars parce qu'il avait la note qu'ils me donnaient à donner à Olaf.

Ok, bien sûr, je préférerais lui donner 30 $ de ma poche. Mais maintenant qu'il avait cette note je pouvais juste dire à la banque de le laisser prendre 30 $ chaque semaine, alors je pourrais juste me présenter à la boulangerie et je ne devais plus aller à la banque. Je pourrais même commander le beignet par téléphone si je le voulais.

Bien sûr, je ne ferais jamais ça - ce beignet était dégoûtant.

Je me demande si cette approche a des applications plus larges. Il a mentionné que c'était sa deuxième approche, je pourrais l'appeler Olaf 2.0. En tout cas je ferais mieux de rentrer à la maison, je dois commencer à chercher un nouvel emploi. Mais avant que je reçoive l'un de ces fraises fraises de cette nouvelle ville, j'ai besoin de quelque chose pour laver le goût de ce beignet.


1269
2017-09-12 01:26



Sur la base de ce que j'ai lu, voici comment tout cela fonctionne:

Le flux général décrit dans la question est correct. Dans l'étape 2, l'utilisateur X est authentifié, et autorise également l'accès du site aux informations de l'utilisateur X sur le site B. Dans l'étape 4, le site passe son secret retour au site B, s'authentifier, ainsi que le code d'autorisation, ce qui indique que c'est demandé (jeton d'accès de l'utilisateur X).

Dans l'ensemble, OAuth 2 est en fait un modèle de sécurité très simple, et le cryptage ne vient jamais directement en jeu. Au lieu de cela, le secret et le jeton de sécurité sont essentiellement des mots de passe, et le tout n'est sécurisé que par la sécurité de la connexion https.

OAuth 2 n'a aucune protection contre les attaques par rejeu du jeton de sécurité ou du secret. Au lieu de cela, il se fie entièrement au fait que le Site B soit responsable de ces éléments et ne les laisse pas sortir, et qu'ils soient envoyés via https pendant le transit (https protégera les paramètres d'URL).

L'étape du code d'autorisation a simplement pour but la commodité, et le code d'autorisation n'est pas particulièrement sensible en soi. Il fournit un identificateur commun pour le jeton d'accès de l'utilisateur X pour le site A lorsqu'il demande au site B le jeton d'accès de l'utilisateur X. L'ID utilisateur de Just User X sur le site B n'aurait pas fonctionné, car de nombreux jetons d'accès en attente pouvaient être distribués sur différents sites en même temps.


121
2018-02-09 22:34



OAuth est un protocole avec lequel une application à 3 parties peut accéder à vos données stockées sur un autre site Web sans votre compte et votre mot de passe. Pour une définition plus officielle, reportez-vous au wiki ou à la spécification.

Voici une démo de cas d'utilisation:

  1. Je me connecte à LinkedIn et je veux connecter des amis qui sont dans mes contacts Gmail. LinkedIn supporte cela, donc je clique sur ce bouton:
    Add Connection

  2. Une page Web s'ouvre et affiche la page de connexion Gmail lorsque j'entre mon compte et mon mot de passe:
    Add Connection

  3. Gmail affiche ensuite une page de consentement dans laquelle je clique sur "Accepter": Add Connection

  4. Maintenant, LinkedIn peut accéder à mes contacts dans Gmail: Add Connection

Voici un organigramme de l'exemple ci-dessus:

Add Connection

Étape 1: LinkedIn demande un jeton à partir du serveur d'autorisation de Gmail.

Étape 2: Le serveur d'autorisation Gmail authentifie le propriétaire de la ressource et lui montre la page de consentement. (l'utilisateur doit se connecter à Gmail s'il n'est pas déjà connecté)

Étape 3: l'utilisateur accorde la demande d'accès à LinkedIn aux données Gmail.

Étape 4: le serveur d'autorisation Gmail répond avec un jeton d'accès.

Étape 5: LinkedIn appelle l'API Gmail avec ce jeton d'accès.

Étape 6: Le serveur de ressources Gmail renvoie vos contacts si le jeton d'accès est valide. (Le jeton sera vérifié par le serveur de ressources Gmail)

Vous pouvez obtenir plus de détails sur OAuth ici.


86
2017-10-09 07:38



Figure 1, soulevée de RFC6750:

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

20
2017-08-03 22:04



Voici comment fonctionne Oauth 2.0, bien expliqué dans Cet article

enter image description here


10
2018-05-10 18:28



C'est un bijou:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Très bref résumé:

OAuth définit quatre rôles:

  1. Propriétaire de la ressource
  2. Client
  3. Serveur de ressources
  4. Serveur d'autorisation

Vous (propriétaire de ressource) avez un téléphone portable. Vous disposez de plusieurs comptes de messagerie différents, mais vous souhaitez que tous vos comptes de messagerie soient regroupés dans une même application. Vous n'avez donc pas besoin de changer de compte. Donc votre GMail (Client) demande l'accès (via le Serveur d'Autorisations de Yahoo) à vos emails Yahoo (Serveur de Ressources) afin que vous puissiez lire les deux emails sur votre application GMail.

La raison pour laquelle OAuth existe est parce que GMail n'est pas sécurisé pour stocker votre nom d'utilisateur et mot de passe Yahoo.

enter image description here


7
2018-06-10 21:22



L'autre réponse est très détaillée et répond à l'essentiel des questions soulevées par le PO.

Pour élaborer, et en particulier pour répondre à la question de l'OP "Comment OAuth 2 protège contre des choses comme les attaques de rejeu en utilisant le jeton de sécurité?", Il y a deux protections supplémentaires dans les recommandations officielles pour exécution OAuth 2:

1) Les jetons auront généralement une courte période d’expiration (http://tools.ietf.org/html/rfc6819#section-5.1.5.3):

Une courte durée d'expiration pour les jetons est un moyen de protection contre   les menaces suivantes:

  • rejouer...

2) Lorsque le jeton est utilisé par le site A, il est recommandé de le présenter non pas comme des paramètres d'URL, mais dans le champ d'en-tête de demande d'autorisation (http://tools.ietf.org/html/rfc6750):

Les clients DEVRAIENT faire des demandes authentifiées avec un jeton de support en utilisant   le champ d'en-tête de demande "Authorization" avec le HTTP "Bearer"   schéma d'autorisation.   ...

La méthode "application / x-www-form-urlencoded" NE DEVRAIT PAS être utilisée   sauf dans les contextes d'application où les navigateurs participants ne   avoir accès au champ d'en-tête de demande "Authorization".   ...

URI Query Parameter ... est inclus pour documenter l'utilisation actuelle; son utilisation n'est pas   recommandé, en raison de ses lacunes de sécurité


6
2018-04-24 14:26