Sí, puede proteger sus conexiones WebSocket con OAuth. Kaazing WebSocket Gateway tiene una arquitectura elegante para autenticación y autorización utilizando una variedad de métodos (basado en token, basado en HTTP o basado en cookies).
Además, está hecho de una manera segura en la Web, donde puede tratar con clientes que no son de confianza. (O al menos, siempre debe asumir que está tratando con clientes que no son de confianza.)
Cuando un cliente intenta una conexión WebSocket, la puerta de enlace recibe la solicitud. Si el servicio particular (es decir, URL) se ha configurado para protegerse, el cliente será desafiado.
Al recibir el desafío que el cliente necesita, a continuación, proporcione un token (suponiendo que eso es lo que se ha configurado en este caso). Si el cliente ya tiene el token, porque ya se han registrado en otro sistema o página web, entonces es genial. Si no, entonces debe obtener uno. Esto depende completamente de su elección de seguridad. En este caso, se pone en contacto con el proveedor de tokens de OAuth para obtener un token. Eso puede significar que el usuario debe proporcionar las credenciales.
Una vez que el cliente tiene un token, lo envía a la puerta de enlace como respuesta al desafío. Gateway es compatible con la arquitectura JAAS estándar, por lo que puede conectar módulos de inicio de sesión para realizar la autenticación necesaria. En este caso, puede enviar el token al proveedor de tokens para determinar si es un token válido.
Si es así, la conexión WebSocket se abre y puede continuar. De lo contrario, la solicitud se rechaza y la conexión se cierra.
Esto tiene el beneficio de proteger sus aplicaciones de back-end: solo los usuarios válidos pasarán por la puerta de enlace. Además, debido a que Kaazing WebSocket Gateway puede vivir en la DMZ, los usuarios no autenticados ni siquiera ingresan a la red de confianza dentro de su firewall principal. Fracasan rápido en el exterior.
Esta arquitectura es potente porque no importa qué marco de seguridad haya elegido, Kaazing's Gateway se conectará a él, en lugar de imponerle su propio mecanismo de seguridad. Además, en el caso de OAUth u OAuth2, no es necesario que comprenda o decodifique el token. El proveedor de tokens es el único que necesita comprenderlo.Pero si su proveedor de tokens quiere especificar una duración para la sesión, puede incluirse junto con el token y Gateway lo respetará.
Si las aplicaciones basadas en navegador no son seguras, podría soportarlo, pero quiero asegurarme de que al menos las aplicaciones basadas en la web tengan una forma segura de acceder al websocket.
Las aplicaciones basadas en web y basadas en navegador se pueden proteger con la arquitectura y la implementación correctas. En Kaazing siempre operamos bajo la suposición de que está tratando con clientes que no son de confianza en la Web y construye nuestra arquitectura en consecuencia.
Éstos son secciones par de la documentación que tienen una descripción de alto nivel:
Saludos, Robin responsable de producto de Kaazing
que es una buena solución si se necesita una autenticación de usuario, pero no estoy muy seguro de si funciona sólo si el cliente necesita autenticarse como en la concesión de credenciales del cliente en el borrador de oauth-2 http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.4. Allí también dice que debe usarse solo para clientes confidenciales. Pero incluso si tiene un cliente confidencial y luego envía la entrada de acceso al navegador (para establecer la conexión ws), queda expuesto. Por lo tanto, para protegerlo de ser reutilizado, permitiría que este accessToken solo se use durante un tiempo muy breve o restrinja el acceso a uno. – JustGoscha