Est-il possible de sécuriser les API WebSocket avec OAuth 2.0?
je suis en train de mettre en place un fournisseur de réseau pour sécuriser différents API basées sur le web. Le plus grand mal de tête est de me donner la sécurisation de WebSockets à travers OAuth.
peut-on le faire en toute sécurité dans un client qui est configuré dans un navigateur?
Quels sont les risques s'il est dans un navigateur par rapport à une application web avec un serveur?
je veux utiliser 2-legged OAuth pour restreindre les connexions au websocket, de sorte que seuls les clients enregistrés peuvent acquérir un WebSocket connexion à L'API sans être refusée. Depuis une connexion WebSocket est toujours (!) établi du côté du client (à partir du navigateur), est-il possible de protéger l'accessToken contre le vol et l'usage abusif?
À ce moment-là, la seule chose qui définit un client basé sur un navigateur à partir d'un client d'application web appart est L'URL.
si les applications basées sur le navigateur sont dangereuses, je pourrais vivre avec cela, mais je veux m'assurer qu'au moins les applications basées sur le web ont un accès sécurisé au websocket.
mais à ce point je me demande si l'accessstoken est nécessaire à tous, parce que que je ne pouvais utiliser l'origine-URI que comme mécanisme sécurisé.
2 réponses
Oui, vous pouvez sécuriser vos connexions WebSocket en utilisant OAuth. Kaazing WebSocket Gateway a une architecture élégante pour l'authentification et l'autorisation en utilisant une variété de méthodes (basées sur les tokens, LES HTTP ou les cookies).
en outre, il est fait d'une manière qui est Sécuritaire sur le Web où vous pouvez traiter avec des clients non fiables. (Ou du moins, vous devriez toujours supposer que vous avez affaire à des clients non fiables.)
Lorsqu'un client tente Connexion WebSocket, la Passerelle reçoit la demande. Si le service (URL) a été configuré pour être protégé, le client sera remis en cause.
après avoir reçu le challenge, le client doit ensuite fournir un token (en supposant que c'est ce qui a été configuré dans ce cas). Si le client a déjà le token -- parce qu'il a déjà signé sur un autre système ou une autre page web -- alors c'est génial. Si non, alors il doit être en obtenir un. Cela dépend entièrement de vous le choix de la sécurité. Dans ce cas, il contacte le fournisseur de token OAuth pour obtenir un token. Cela peut signifier que l'utilisateur doit fournir des justificatifs d'identité.
une fois que le client a un jeton, il l'envoie à la passerelle en réponse au défi. La passerelle prend en charge L'architecture JAAS standard de sorte que vous pouvez brancher des modules de connexion pour effectuer l'authentification nécessaire. Dans ce cas, il peut envoyer le jeton pour le fournisseur de jeton afin de déterminer si c'est un jeton valide.
si elle is, la connexion WebSocket est ouverte et peut continuer. Sinon, la demande est rejetée et la connexion est fermée.
ceci a l'avantage de protéger vos applications back-end -- seuls les utilisateurs valides passeront par la passerelle. De plus, parce que la passerelle WebSocket de Kaazing peut vivre dans la DMZ, les utilisateurs non authentifiés n'entrent jamais dans le réseau de confiance de votre pare-feu principal. Ils ne parviennent pas rapidement à l'extérieur.
Cette architecture est puissante parce qu'elle peu importe le cadre de sécurité que vous avez choisi, la passerelle de Kaazing s'y connectera plutôt que de vous imposer son propre mécanisme de sécurité. En outre, dans le cas de OAUth ou OAuth2, il n'a pas besoin de comprendre ou de décoder le token. Le fournisseur de jetons est le seul qui doit le comprendre. Mais si votre fournisseur de token veut spécifier une durée pour la session, cela peut être inclus avec le token et la passerelle l'honorera.
si basé sur le navigateur les applications sont dangereuses, je pourrais vivre avec ça, mais je veux m'assurer qu'au moins les applications basées sur le web ont un moyen sécurisé d'accéder au websocket.
les applications basées sur le web et les navigateurs peuvent être sécurisées avec la bonne architecture et mise en œuvre. Chez Kaazing, nous partons toujours du principe que vous traitez avec des clients non fiables sur le Web et que vous construisez notre architecture en conséquence.
voici quelques sections de la documentation qui ont une description de haut niveau:
- Ce Qui Se Passe Lors De L'Authentification
- comment L'authentification et L'autorisation fonctionnent avec la passerelle
ce qui Concerne, Robin Chef De Produit, Kaazing
une subvention de justificatifs d'identité est seulement aussi sûre que l'authentification effectuée avant de distribuer le jeton d'accès. C'est en dehors des spécifications qu'ils disent. Cela dépend donc du régime d'authentification que vous décidez de mettre en place avant de donner des jetons en réponse à des subventions de justificatifs d'identité.
maintenant, supposons que vous avez mis en place une façon sécurisée d'obtenir votre subvention d'authentification, ou d'obtenir un jeton d'accès dans votre navigateur via une demande régulière OAuth2.
sous le OAuth2 spécification vous êtes libre de Mac-digest portions, encrypt portions ou de protéger les données à l'intérieur de ce token de plusieurs façons. La sécurité du jeton d'accès dans le navigateur dépend des informations qu'il contient - souvent les gens le conçoivent pour contenir des informations minimales (userid, expiration-temps, version, digest) et le rendent auto-vérifiable par votre serveur (d'où le digest). Le contenu du jeton sont presque arbitraire. Certains systèmes donnent même des "codes" d'accès comme jeton.
supposons maintenant que vous avez un jeton d'accès "format sécurisé" protégé, avec une restriction de temps. Prenons un exemple concret: Facebook et son implémentation OAuth2. Qu'il s'agisse d'un jeton d'accès complet ou d'un code d'accès pour la récupération de justificatifs côté serveur (avec des restrictions de temps pour chaque jeton), vous pouvez envoyer le jeton (ou le code) à partir du navigateur pour sécuriser l'accès à un WebSocket, en utilisant la passerelle Kaazing.
une des choses que j'ai enlevées au travail La passerelle de Kaazing est que OAUth2 ne sécurise vraiment rien - vous êtes libre de distribuer des jetons d'accès de forme arbitraire. C'est une bonne idée de vous assurer que votre système d'authentification des justificatifs d'identité, le format access_token et access_token lifetime sont tous de bonnes décisions de politique-puis vous obtenez la sécurité.
la passerelle Kaazing vous permet d'envoyer des jetons arbitraires dans la passerelle et de les valider avec un module de connexion JAAS que vous écrivez pour les vérifier. La sécurité du régime est à vous et à des décisions politiques.
Cordialement,
Steven Atkinson
Développeur De Serveur De Passerelle, Kaazing