Es el token necesario para actualizar con HTTPS

1

Entiendo completamente los beneficios del token de actualización en el caso de que el token de acceso se vea comprometido.

Envío el token de acceso JWT al servidor solo a través de HTTPS para una aplicación móvil y una aplicación web que necesita un inicio de sesión de por vida. Así que creo que el token de acceso no se puede comprometer a menos que el dispositivo del usuario esté en manos del atacante. Nuevamente, si el dispositivo del usuario está en las manos del atacante, tanto el token de actualización como el token de acceso se verían comprometidos.

¿Hay alguna otra forma de comprometer el token de acceso? Si NO, en mi caso, ¿es necesario tener un sistema de token de actualización?

ACTUALIZACIÓN 1: uso solo un servidor. No hay un servidor de autenticación y un servidor de recursos separados.

    
pregunta Aswin Kumar K P 05.07.2017 - 14:34
fuente

1 respuesta

2

Una diferencia importante entre los tokens de acceso y los tokens de actualización es quién puede verlos.

El Servidor de Autorización entrega el token de acceso y, a continuación, el cliente lo utiliza para obtener acceso a los recursos del Propietario del recurso. El token de acceso lo ven tanto el servidor de autorización, el cliente y el servidor de recursos.

El Servidor de autorización distribuye el token de actualización y solo lo ven el Cliente y el Servidor de autorización. El servidor de recursos nunca ve el token de actualización.

Por lo tanto, el token de acceso es más vulnerable; Es visto por más partidos. Una implementación descuidada en el Servidor de recursos podría provocar la filtración del token de acceso, mientras que el token de actualización aún sería seguro.

Crédito: recibí ayuda de esta respuesta de desbordamiento de pila al escribir esto.
Un escenario que menciona es que el token de acceso podría enviarse como un parámetro de consulta y luego terminar en un archivo de registro. El token de acceso estaba protegido por HTTPS durante el tránsito, pero ahora se encuentra en el archivo de registro en el servidor de recursos. Las personas que no tienen derecho a conocer el token de acceso, pueden tener derecho a ver el archivo de registro. Por ejemplo, los estudiantes que tienen un trabajo de verano como soporte técnico.

Lo importante, sin embargo, no es intentar e inventar un escenario específico en el que las cosas puedan salir mal. Lo importante es darse cuenta de que el token de acceso podría tener fugas y el token de actualización sigue siendo seguro. Es una forma de programación defensiva: prepárese para el caso de que exista una vulnerabilidad en el servidor de recursos.

Dado que en la situación dada, el Servidor de autorización y el Servidor de recursos son una aplicación única, la mayoría de los escenarios en los que el token de acceso está comprometido también tendrán un compromiso del token de actualización.

Como nota al margen, he trabajado en un escenario similar. Utilizamos el servidor de identidad como el servidor de autorización. Fue incorporado en la aplicación. Si esa aplicación se filtró, primero vería la parte del Servidor de recursos. Identity Server está creado por expertos en seguridad y, al ser de código abierto, ha sido examinado por muchos. La parte del servidor de recursos de esa aplicación en particular era propietaria. Es posible que también desee consultar Identity Server para su aplicación.

    
respondido por el S.L. Barth 05.07.2017 - 14:55
fuente

Lea otras preguntas en las etiquetas