OAuth jeton d'accès vs clé de session
Y a-t-il un avantage à OAuth par rapport aux sessions basées sur les cookies (établies via le nom d'utilisateur/mot de passe) dans les hypothèses suivantes?
- Il n'y a qu'un seul client légitime au service
- Le OAuth secret client a été compromis (donc des demandes valides peuvent être émises par n'importe qui)
- Le jeton OAuth et la session ont la même durée de vie
- Les deux permettent d'accéder au même ensemble de ressources avec les mêmes privilèges
- Toutes les communications client-serveur sous l'un ou l'autre des schémas se font via le même protocole (pour des raisons d'argument, HTTPS)
- Le client et le serveur sont contrôlés par la même partie
En fait ça dépend...
OAuth est un protocole pour créer une session. OAuth les jetons au porteur sont transmis par le client en utilisant le Authentication: Bearer En-tête HTTP. Il s'agit simplement d'un nonce cryptographique qui est transmis via un élément d'en-tête http, qui est en effet ( presque) identique à l'élément d'en-tête cookie http.
Comment est-ce différent? Eh bien, les règles pour les cookies sont un peu différentes des autres éléments d'en-tête. Le cookie est géré par le navigateur , et est joint à chaque demande à laquelle appartient le cookie. C'est la raison pour laquelle Cross-Site Request Forgery ou les attaques d'équitation de session fonctionnent. Le navigateur ne se soucie pas d'où vient la demande, il attachera le cookie en fonction de la destination de la demande.
Les jetons OAuth Bearer sont un peu différents. Ces jetons sont généralement gérés par le client (JavaScript, Flash ou même une application middleware). Si votre application utilise JavaScript pour gérer le jeton du porteur d'authentification, cette valeur ne sera pas automatiquement appliquée par le navigateur , et pourra donc doubler comme un jeton CSRF , ce qui est bien.
Cependant, si vous utilisez OAuth pour le middleware, alors CSRF n'entre pas en jeu, donc peu importe où il apparaît dans l'en-tête.
CSRF est déjà protégé par tous les navigateurs modernes, s'il ne joint pas simplement un cookie en fonction de la destination, s'il valide autorise la politique d'origine avant de l'envoyer au serveur, donc après une recherche, oauth2 et l'authentification basée sur la session ont la même sécurité le risque et la seule différence est l'en-tête utilisé