security - google - oauth2 java

¿Es posible asegurar las API de WebSocket con OAuth 2.0? (2)

Una concesión de credenciales es tan segura como la autenticación realizada antes de entregar el token de acceso. Eso está fuera de la especificación que dicen. De modo que eso depende del régimen de autenticación que decida poner delante de los tokens en respuesta a las concesiones de credenciales.

Ahora, supongamos que ha configurado una forma segura y agradable de obtener sus credenciales, u obtenga un token de acceso en su navegador a través de una solicitud normal de OAuth2.

Según la especificación OAuth2, puede mapear porciones de CIT, encriptar porciones o proteger los datos dentro de ese token de muchas maneras. La seguridad del token de acceso en el navegador depende de la información que contiene; a menudo las personas lo diseñan para que contenga información mínima (ID de usuario, tiempo de caducidad, versión, resumen) y lo hace autoverificable por su servidor (de ahí el resumen) . El contenido del token es virtualmente arbitrario. Algunos sistemas incluso dan acceso a "códigos" como proxies para el token.

Ahora supongamos que tiene un token de acceso de "formato seguro" protegido, con una restricción de tiempo. Consideremos un ejemplo del mundo real: Facebook y su implementación de OAuth2. Ya sea un token de acceso completo o un código de acceso para la recuperación de credenciales del lado del servidor (cada uno con restricciones de tiempo) puede enviar el token (o código) desde el navegador para asegurar el acceso a un WebSocket, utilizando Kaazing Gateway.

Una de las cosas que me he negado de trabajar con Kaazing es que OAUth2 realmente no asegura nada: usted es libre de entregar tokens de acceso de forma arbitraria. Es una buena idea asegurarse de que su esquema de autenticación de credenciales, el formato access_token y el access_token de por vida sean todas buenas decisiones de política, entonces usted obtiene seguridad.

Kaazing Gateway le permitirá enviar tokens arbitrarios a la puerta de enlace y validarlos con un módulo de inicio de sesión JAAS que escriba para verificarlos. La seguridad del régimen depende de usted y de las decisiones políticas.

Saludos,

Steven Atkinson

Desarrollador de servidor Gateway, Kaazing

Estoy implementando un proveedor de OAuth para asegurar diferentes API basadas en web. El mayor dolor de cabeza es para asegurarme WebSockets a través de OAuth.

¿Se puede hacer completamente seguro en un cliente que está configurado en un navegador?

¿Cuáles son los riesgos si está en un navegador en comparación con una aplicación web con un servidor?

Quiero utilizar OAuth de 2 patas para restringir las conexiones al websocket, de modo que solo los clientes registrados pueden adquirir una conexión WebSocket a la API sin que se rechacen. Como siempre se establece (!) Una conexión WebSocket en el lado del cliente (desde el navegador), ¿es posible proteger el accessToken de ser robado y mal utilizado?
En ese punto, lo único que establece un cliente basado en navegador desde una aplicación de cliente de aplicación web es la URL.

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.

Pero en ese momento me pregunto si el accessToken es necesario en absoluto, porque de lo que podría simplemente usar el URI de origen como único mecanismo seguro.

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 tokens, basado en HTTP o basado en cookies).

Además, se realiza 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, el Gateway recibe la solicitud. Si el servicio particular (es decir, URL) se ha configurado para protegerse, el cliente será desafiado.

Al recibir el desafío, el cliente debe proporcionar 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 al Gateway 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 la ventaja 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 poderosa 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 pueden hacerse seguras 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.

Aquí hay un par de secciones de la documentación que tienen una descripción de alto nivel:

Saludos, Robin Product Manager, Kaazing