Comment OAuth 2 protège-t-il contre des choses comme les attaques par rejeu à l'aide du jeton de sécurité?

Si je comprends bien, la chaîne d'événements suivante se produit dans OAuth 2 afin Site-Ad'accéder aux informations de l' utilisateur à partir de Site-B.

1. Site-As'inscrit Site-Bet obtient un Secret et une ID.
2. Lorsque l' utilisateur dit Site-Ad'accéder Site-B, l' utilisateur est envoyé à l' Site-Bendroit où il indique Site-Bqu'il souhaite en effet accorder des Site-Aautorisations à des informations spécifiques.
3. Site-Bredirige l' utilisateur vers Site-A, avec un code d'autorisation.
4. Site-Atransmet ensuite ce code d'autorisation avec son secret Site-Ben échange d'un jeton de sécurité.
5. Site-Aeffectue ensuite des demandes au Site-Bnom de l' 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 choses comme les attaques par rejeu à l'aide du jeton de sécurité?

Fonctionnement d'OAuth 2.0 dans la vie réelle:

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

Ouais je sais, 30 $ pour un beignet! Ça doit être délicieux! J'ai atteint mon portefeuille quand soudain j'ai entendu le chef crier "NON! Pas de beignet pour toi". J'ai demandé: pourquoi? Il a dit qu'il n'acceptait que les virements bancaires.

Sérieusement? Oui, il était sérieux. J'ai failli m'éloigner juste là, mais ensuite le beignet m'a crié: "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 (le chef, pas le beignet): "Dis-leur qu'Olaf t'a envoyé". Son nom était déjà sur la note, donc je ne sais pas à quoi ça servait, mais ok.

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

Elle a pris ma note, a demandé mon identité, m'a demandé combien d'argent était acceptable pour lui donner. Je lui ai dit 30 $. Elle a griffonné et m'a remis une autre note. Celui-ci avait un tas de chiffres dessus, je suppose que c'est ainsi qu'ils gardent une trace des notes.

À ce stade, je meurs de faim. Je me suis précipité hors de là, une heure et demie plus tard j'étais de retour, debout devant Olaf avec ma note étendue. Il l'a pris, l'a regardé et a dit: "Je reviendrai".

Je pensais qu'il recevait mon beignet, mais après 30 minutes, j'ai commencé à me méfier. J'ai donc 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 note que la banque m'a donné et est retourné à la banque pour retirer de l'argent de mon compte. Puisqu'il avait le billet que la banque m'a donné, la banque savait que c'était le gars dont je parlais, et parce que j'ai parlé avec la banque, elle savait qu'elle ne devait lui donner que 30 $.

Cela a dû me prendre beaucoup de temps pour comprendre cela car au moment où je levai les yeux, Olaf se tenait devant moi, me tendant enfin mon beignet. Avant de partir, j'ai dû demander: "Olaf, as-tu toujours vendu des beignets de cette façon?". "Non, je le faisais différemment."

Huh. Alors que je retournais à 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 pour me virer, mon patron est vraiment un ***. D'ailleurs, j'étais pris de réflexion sur le processus que je venais de traverser.

Je veux dire, pensez-y: j'ai pu laisser Olaf retirer 30 $ de mon compte bancaire sans avoir à lui donner les informations de mon compte. Et je n'avais pas à m'inquiéter qu'il retirerait trop d'argent parce que j'avais déjà dit à la banque qu'il n'était autorisé qu'à prendre 30 $. Et la banque savait qu'il était le bon gars parce qu'il avait le billet qu'ils m'avaient donné à donner à Olaf.

D'accord, je préfère lui donner 30 $ de ma poche. Mais maintenant qu'il avait cette note, je pouvais simplement dire à la banque de le laisser prendre 30 $ chaque semaine, alors je pouvais simplement me présenter à la boulangerie et je n'avais plus besoin d'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. Quoi qu'il en soit, je ferais mieux de rentrer chez moi, je dois commencer à chercher un nouvel emploi. Mais pas avant d'avoir obtenu un de ces shakes aux fraises de ce nouvel endroit à travers la ville, j'ai besoin de quelque chose pour laver le goût de ce beignet.

D'après ce que j'ai lu, voici comment tout cela fonctionne:

Le flux général décrit dans la question est correct. À l'étape 2, l'utilisateur X est authentifié et autorise également l'accès du site A aux informations de l'utilisateur X sur le site B. À l'étape 4, le site retransmet son secret au site B, s'authentifiant ainsi que le code d'autorisation, indiquant ce qui il demande (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 chiffrement n'entre 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 de rejeu du jeton de sécurité ou du secret. Au lieu de cela, il repose entièrement sur le site B qui est responsable de ces éléments et ne les laisse pas sortir, et sur leur envoi via https pendant le transport (https protégera les paramètres d'URL).

Le but de l'étape du code d'autorisation est simplement la commodité, et le code d'autorisation n'est pas particulièrement sensible en soi. Il fournit un identifiant commun pour le jeton d'accès de l'utilisateur X pour le site A lors de la demande du site B pour le jeton d'accès de l'utilisateur X. Le simple identifiant de l'utilisateur X sur le site B n'aurait pas fonctionné, car il pourrait y avoir de nombreux jetons d'accès en attente en attente d'être distribués à différents sites en même temps.

OAuth est un protocole avec lequel une application tierce 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émonstration de cas d'utilisation:

1. Je me connecte à LinkedIn et souhaite connecter des amis qui figurent dans mes contacts Gmail. LinkedIn soutient cela. Il demandera une ressource sécurisée (ma liste de contacts gmail) à gmail. Je clique donc sur ce bouton:
   

2. Une page Web apparaît et affiche la page de connexion Gmail, lorsque j'entre mon compte et mon mot de passe:
   

3. Gmail affiche ensuite une page de consentement où je clique sur "Accepter":

4. LinkedIn peut désormais accéder à mes contacts dans Gmail:

Voici un organigramme de l'exemple ci-dessus:

Étape 1: LinkedIn demande un jeton au serveur d'autorisation de Gmail.

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

Étape 3: l'utilisateur accepte la demande de LinkedIn d'accéder aux données Gmail.

Étape 4: le serveur d'autorisation Gmail répond en retour 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 d'informations sur OAuth ici .

Figure 1, relevée du 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 ---|               |
     +--------+                               +---------------+

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

Ceci est un joyau:

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 la ressource) avez un téléphone portable. Vous avez plusieurs comptes de messagerie différents, mais vous voulez que tous vos comptes de messagerie dans une seule application, vous n'avez donc pas besoin de continuer à changer. Ainsi, votre GMail (client) demande l'accès (via le serveur d'autorisation de Yahoo) à vos e-mails Yahoo (serveur de ressources) afin que vous puissiez lire les deux e-mails sur votre application GMail.

La raison pour laquelle OAuth existe est qu'il n'est pas sûr que GMail stocke votre nom d'utilisateur et votre mot de passe Yahoo.

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

Pour élaborer, et spécifiquement pour répondre à la question du PO "Comment OAuth 2 protège-t-il contre des choses comme les attaques par rejeu à l'aide du jeton de sécurité?", Il existe deux protections supplémentaires dans les recommandations officielles pour la mise en œuvre d' 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 ):

Un court délai 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 en tant que 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 porteur en utilisant le champ d'en-tête de demande "Autorisation" avec le schéma d'autorisation HTTP "Porteur". ...

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

Le paramètre de requête URI ... est inclus pour documenter l'utilisation actuelle; son utilisation n'est pas recommandée, en raison de ses failles de sécurité

Voici peut-être l'explication la plus simple du fonctionnement d'OAuth2 pour les 4 types de subvention, c'est-à-dire 4 flux différents où l'application peut acquérir le jeton d'accès.

Similarité

Tous les flux de type de subvention ont 2 parties:

• Obtenir un jeton d'accès
• Utiliser un jeton d'accès

La 2ème partie 'utiliser le jeton d'accès' est la même pour tous les flux

Différence

La première partie du flux «obtenir un jeton d'accès» pour chaque type de subvention varie.

Cependant, en général, la partie «obtenir un jeton d'accès» peut être résumée en 5 étapes:

1. Pré-enregistrez votre application (client) auprès du fournisseur OAuth, par exemple Twitter, etc. pour obtenir l'identifiant / secret du client
2. Créez un bouton de connexion sociale avec l'ID client et les étendues / autorisations requises sur votre page afin que l'utilisateur cliqué soit redirigé vers le fournisseur OAuth pour être authentifié
3. Le fournisseur OAuth demande à l'utilisateur d'accorder l'autorisation à votre application (client)
4. Le fournisseur OAuth émet du code
5. L'application (client) acquiert un jeton d'accès

Voici un diagramme côte à côte comparant en quoi chaque flux de type de subvention est différent en fonction des 5 étapes.

Ce diagramme provient de https://blog.oauth.io/introduction-oauth2-flow-diagrams/

Chacun a différents niveaux de difficulté de mise en œuvre, de sécurité et de cas d'utilisation. Selon vos besoins et votre situation, vous devrez en utiliser un. Lequel utiliser?

Informations d'identification du client : si votre application ne sert qu'un seul utilisateur

Informations d'identification du mot de passe du propriétaire de la ressource : cela ne doit être utilisé qu'en dernier recours, car l'utilisateur doit remettre ses informations d'identification à l'application, ce qui signifie que l'application peut faire tout ce que l'utilisateur peut faire.

Code d'autorisation : la meilleure façon d'obtenir l'autorisation de l'utilisateur

Implicite : si votre application est une application mobile ou une seule page

Il y a plus d'explications sur le choix ici: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/