Comment OAuth 2 protège-t-il contre des attaques telles que la réexécution d'attaques utilisant le jeton de sécurité?

Question

D'après ce que je comprends, la chaîne d'événements suivante se produit dans OAuth 2 afin que Site-A puisse accéder à tilisateur les informations de Site-B.

1. Site-A s'enregistre sur Site-B et obtient un secret et un identifiant.
2. Lorsque tilisateur indique à Site-A d’accéder à Site-B, tilisateur est envoyé à Site-B où il indique à Site-B qu’il le ferait. aime bien donner Site-A autorisations sur des informations spécifiques.
3. Site-B redirige tilisateur vers Site-A, avec un code d'autorisation.
4. Site-A transmet ensuite ce code d'autorisation avec son code secret à Site-B en échange d'un jeton de sécurité.
5. Site-A fait ensuite des demandes à Site-B pour le compte de ser 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 attaques telles que la réexécution d'attaques utilisant le jeton de sécurité?

Answer 1

D'après ce que j'ai lu, voici comment 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 en s'authentifiant, ainsi que le code d'autorisation c'est demander (jeton d'accès de l'utilisateur X).

De manière générale, OAuth 2 est en réalité un modèle de sécurité très simple et le cryptage ne joue jamais directement. Au lieu de cela, le secret et le jeton de sécurité sont essentiellement des mots de passe et le tout est sécurisé uniquement par la sécurité de la connexion https.

OAuth 2 ne dispose d'aucune protection contre les attaques par rejeu du jeton de sécurité ou du secret. Au lieu de cela, il repose entièrement sur le fait que le site B assume la responsabilité de ces éléments sans les laisser sortir et leur envoi via https en transit (https protégera les paramètres d'URL).

Le but de l’étape Code d’autorisation est tout simplement pratique 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 lorsqu'il demande au site B le jeton d'accès de l'utilisateur X. L'identifiant d'utilisateur Just X sur le site B n'aurait pas fonctionné, car de nombreux jetons d'accès en attente pourraient être remis en même temps à différents sites.

Answer 2

Comment OAuth2.0 fonctionne dans la vie réelle:

Je me rendais au travail près de la boulangerie d'Olaf quand j'ai vu le beignet le plus délicieux à la fenêtre. Je veux dire, le truc dégoulinait de chocolat. Alors je suis entré et j'ai demandé "Je dois avoir ce beignet!". Il a dit "bien sûr que ce sera 30 $."

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

Sérieusement? Oui, il était sérieux. J'ai failli m'en aller là, mais le beignet m'a alors crié: "Mange-moi, je suis délicieux ...". Qui suis-je pour désobéir aux ordres d'un beignet? J'ai dit ok.

Il me tendit une note avec son nom (le chef, pas le beignet): "Dis-leur qu'Olaf t'a envoyé". Son nom figurait déjà sur la note, alors je ne sais pas à quoi ça servait, mais d'accord.

J'ai conduit une heure et demie à 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, demandé mon identifiant, m'a demandé combien d'argent je pouvais lui donner. Je lui ai dit 30 dollars. Elle a gribouillé et m'a tendu une autre note. Celui-ci contenait une série de chiffres, je suppose que c'est comme ça qu'ils gardent les 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, ma note étendue. Il l'a pris, l'a examiné et a dit: "Je serai de retour".

Je pensais qu'il recevait mon beignet, mais après 30 minutes, j'ai commencé à être suspicieux. 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".

Hein ... alors Olaf a pris la note que la banque m'a donnée et est retourné à la banque pour retirer de l'argent de mon compte. Puisqu'il avait le billet que la banque m'avait donné, la banque savait qu'il était le type dont je parlais et, comme je l'avais parlé à la banque, ils savaient qu'il ne lui donnerait que 30 $.

Cela a dû prendre beaucoup de temps pour comprendre cela car au moment où je levai les yeux, Olaf se tenait devant moi enfin me remettant 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. En revenant à ma voiture, mon téléphone a sonné. Je n'ai pas pris la peine de répondre, c'était probablement mon boulot qui appelait à me virer, mon patron est un imbécile. En outre, j'étais en train de réfléchir au processus que je venais de traverser.

Je veux dire, réfléchissez-y: 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 à craindre qu'il prenne trop d'argent, car j'avais déjà dit à la banque qu'il n'avait le droit que de prendre 30 $. Et la banque savait qu'il était le bon gars parce qu'il avait la note qu'ils m'ont donnée à donner à Olaf.

Ok, bien sûr, je préférerais lui remettre 30 dollars de ma poche. Mais maintenant qu'il avait cette note, je pouvais simplement dire à la banque de le laisser prendre 30 dollars par semaine, alors je pourrais me présenter à la boulangerie et je n'aurais 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égueulasse.

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 un de ces shakes à la fraise de ce nouvel endroit de la ville, j'ai besoin de quelque chose pour effacer le goût de ce beignet.

Answer 3

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. Alors je clique sur ce bouton:
   

2. Une page Web apparaît et affiche la page de connexion à Gmail lorsque je saisis mon compte et mon mot de passe:
   

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

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

Ci-dessous un organigramme de l'exemple ci-dessus:

Étape 1: LinkedIn demande un jeton au serveur d’autorisations de Gmail.

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

Étape 3: l'utilisateur accède à la demande de LinkedIn pour accéder 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 en savoir plus sur les détails concernant OAuth ici .

Answer 4

Figure 1, levée de RFC675 :

     +--------+                               +---------------+
     |        |--(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 ---|               |
     +--------+                               +---------------+

Answer 5

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

Answer 6

C'est un petit bijou:

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

Résumé très bref:

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 tous vos comptes de messagerie dans une seule application. Vous n'avez donc pas besoin de continuer à basculer. Donc, votre GMail (Client) demande l'accès (via le serveur d'autorisations de Yahoo) à vos emails Yahoo (Resource Server) afin que vous puissiez lire les deux emails sur votre application GMail.

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

Answer 7

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

Pour élaborer, et en particulier pour répondre à la question du PO "Comment OAuth 2 se protège-t-elle contre des attaques de rejeu utilisant le jeton de sécurité?", Il existe deux protections supplémentaires dans les recommandations officielles de implémentant OAuth 2:

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

Une courte date d'expiration pour les jetons constitue 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ètre d'URL, mais dans le champ d'en-tête de demande d'autorisation ( http://tools.ietf.org/html/rfc675 =):

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 schéma d'autorisation HTTP "Bearer". ...

La méthode "application/x-www-form-urlencoded" NE DEVRAIT PAS être utilisée sauf dans des 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 problèmes de sécurité

Answer 8

Voici peut-être l'explication la plus simple de la façon dont OAuth2 fonctionne 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 subvention ont 2 parties:

• Accéder au jeton
• Utiliser le 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 1ère partie du flux 'Obtenir un jeton d'accès' pour chaque type d'octroi 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) avec le fournisseur OAuth, par exemple, Twitter, etc. pour obtenir l'ID/le secret du client.
2. Créez un bouton de connexion sociale avec l'ID client et les portées/autorisations requises sur votre page. Ainsi, lorsque l'utilisateur clique dessus, l'utilisateur est redirigé vers le fournisseur OAuth à authentifier.
3. Le fournisseur OAuth demande à l'utilisateur d'accorder la permission à votre application (client).
4. Code du fournisseur OAuth
5. App (client) acquiert un jeton d'accès

Voici un diagramme côte à côte comparant les différences entre chaque flux de type d’octroi en fonction des 5 étapes.

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

Chacun a différents niveaux de difficulté d'implémentation, de sécurité et 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

Identifiant de mot de passe du propriétaire de la ressource : il 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 tout ce que l'utilisateur peut

Code d'autorisation : Le meilleur moyen d'obtenir une autorisation de l'utilisateur

Implicite : Si votre application est mobile ou sur une seule page

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