OAuth 2.0 authentification à deux jambes vs SSL/TLS
j'ai deux serveurs d'entreprise qui ont besoin de communiquer de manière sécurisée, et je compare en utilisant SSL (avec des certs client/serveur pour valider les deux côtés) vs authentification à deux jambes en utilisant OAuth 2.0 (en option avec des tokens MAC ou JWT).
historiquement, OAuth semble avoir été créé pour un but totalement différent (le cas à 3 jambes où un utilisateur permet à un service d'accéder à certaines données quelque part), et bien que two-legged soit maintenant intégré dans le OAuth 2.0 spec, d'après ce que j'ai vu, l'OAuth 2.0 à deux pattes ne semble pas offrir beaucoup de protection supplémentaire sur SSL.
le seul point auquel je peux penser est que OAuth est potentiellement plus facile à configurer que SSL, et il est facile de faire des erreurs avec des choses comme accepter de mauvais certs SSL qui peuvent compromettre la sécurité. Cependant, je ne suis pas sûr que ce soit une raison suffisante pour aller avec OAuth.
notez que je les mentionne comme des options séparées, mais je pense que l'utilisation D'OAuth impliquerait probablement de l'utiliser en plus de HTTPS / SSL, donc les deux seraient utilisés.
y a-t-il un avantage réel à utiliser le schéma à deux jambes OAuth 2.0 pour la communication de serveur à serveur (Aucun utilisateur impliqué)?
Note: je l'a trouve un peu le même post ici, mais c'est assez ancien mais je ne pense pas que a donné une réponse satisfaisante à cette question.
2 réponses
je vais répondre à ce commentaire:
ma question Est que, en supposant que J'utilise SSL avec des certs client/serveur appropriés pour identifier chaque machine, quelle valeur utiliserait OAuth (2 legged ou similaire) en plus de cela pour autoriser les serveurs les uns aux autres (en supposant qu'il n'y a aucun utilisateur impliqué). Merci-Locksleyu
résumé: je ne me donnerais pas la peine de faire les deux.
Détails: 2 pattes OAUTH est aussi sûr que le consommateur secret est. Pareillement l'authentification mutuelle est seulement aussi sûre que la clé privée. Je suppose que vous les stockerez dans un magasin crypté sur chaque serveur. Comme les deux sont stockés au même endroit, Je ne vois pas de sécurité supplémentaire qui vient de l'ajout D'OAUTH.
maintenant, si vous envisagez un choix entre un ssl mutual authl et un SSL standard avec authentification, peut-être que OAUTH peut y jouer un rôle. Je voudrais aller avec n'importe quel de ces options me semble plus facile. Donc, si vous avez un système de OAUTH en place et peut facilement ajouter serveur auth à elle, peut-être que c'est la voie à suivre. Dans le cas contraire, il suffit d'une autorisation mutuelle. Il a tendance à être un peu compliqué à configurer mais fonctionne bien et rapidement une fois configuré.
excuses si vous le savez déjà mais ce n'est pas clair dans votre post.
OAuth et SSL\TLS sont deux couches distinctes du modèle OSI. OAuth est pour l'authentification et se trouve au sommet de la couche 7 tandis que SSL\TLS est pour la sécurité du transport dans la couche 4. Il est facile de confondre SSL et les certificats clients parce qu'ils utilisent tous deux L'ICP.
vous avez raison dans votre compréhension de OAuth...il est utilisé pour autoriser des individus pas des organisations\serveurs. 2-OAuth legged est un terme cela est jeté autour de qui englobent divers flux de OAuth alternate, tous qui ne suivent pas une norme.
à mon avis, vous voulez utiliser des certificats clients pour sécuriser votre communication serveur-serveur...tout ce qui est vraiment requis est un seul certificat x509 qui peut être utilisé à la fois comme SSL (sécurité du transport) et comme certificat client (autorisation); bien que l'utilisation de 2 certificats soit la norme.