token de acceso JWT y token de actualización

Esta es una situación bastante común en la que se encuentra, lo cual es bueno, ya que significa que la solución es bien conocida, discutida y probada.

  

1. ¿Es suficiente una simple verificación de firma por App2? ¿O existe la necesidad de que envíe el token a la App1 para su verificación (hay una lista blanca de claves públicas para la App2)?
  

Correcto, una verificación de firma "simple" es todo lo que App2 necesita hacer para validar el token. Esto garantizará a.) El token fue dispensado por App1 y b.) Los reclamos (pares clave-valor) en el token no se han manipulado.

  

2. Estoy considerando agregar una fecha de vencimiento por 30 minutos, ¿cómo debo manejar el token de actualización en el lado del cliente?
  

Esto se reduce más a las preferencias personales, pero no me gustan los tokens de actualización. Los tokens de actualización implican una fecha de vencimiento futura lejana (es decir, un par de días o una semana) y pueden ser muy dañinos si se los roban. Además, en mi experiencia, no hay una manera realmente buena de almacenar un secreto en el lado del cliente. Las cookies son inseguras y no creo que los DB del lado del cliente sean mucho mejores. Podría cifrarlo con la contraseña del usuario, pero eso requiere que el usuario vuelva a escribir la contraseña que anula el propósito del token de actualización, ¿no? Así que evitaría actualizar tokens si es posible.

  

3. En lugar de los tokens de actualización de la generación, ¿es seguro decir que el token de acceso es de una sola vez y que App2 crea una sesión en el lado del servidor (usando los datos en el token)?
  

No veo ningún defecto en este plan, creo que es mucho más seguro que confiar en un token de actualización. La única advertencia aquí es garantizar que existe la capacidad de anular un token de acceso en App1. En otras palabras, si me autentico contra la App1, obtengo mi token y luego vengo a la App2, me autentico y obtengo mi ID de sesión, estoy feliz. Pero, un atacante podría robar mi token de la cookie de mi navegador. El atacante puede usar este token para obtener su propia sesión con mis credenciales en App2 siempre que el token aún no haya caducado. Por lo tanto, App1 y App2 tendrían que poder comunicarse en este escenario. App2 comprueba que App1 dice que el token aún no se ha utilizado. App2 lo usa, luego le dice a App1 que se usó, anule el token para que no pueda ser reutilizado en futuras solicitudes para generar otro ID de sesión.

Como puedes ver, eso se vuelve mucho más complicado. Pero, si no lo haces, realmente no estás usando tokens de una sola vez. Una alternativa sería que la caducidad del token sea MUY breve (es decir, cinco minutos o menos), tiempo suficiente para que el usuario sea redirigido y autenticado con App2 y obtenga su ID de sesión para la autenticación continua. Esta podría ser la ruta más simple, pero realmente depende del nivel de seguridad que desea alcanzar aquí.

De cualquier manera, el ID de sesión es una idea inteligente. Es probable que reduzca la carga en el servidor de App2, ya que no tendrá que volver a comprobar constantemente las firmas de token para cada solicitud.

Como desarrollador

A menos que su APP 1 esté diseñada para ser un servicio de federación, no debería extender APP1 para que actúe como un servicio de federación. Esto es sólo un mal diseño de software.

Si la APP2 carece de autenticación y autorizaciones, debería, lógicamente, simplemente agregarla a la aplicación. Puede ser un método de SSO, pero asegúrese de que se autentique con un servicio diseñado para realizar la autenticación / autorizaciones.

Si APP1 y APP2 no tienen nada que ver uno con el otro (lo que parece) no CREA UNA DEPENDENCIA A TRAVÉS DE LA AUTENTICACIÓN.

Como profesional de seguridad

Para responder tus preguntas:

1. Esto depende de sus riesgos y de la importancia de estas aplicaciones para la organización. Es posible que desee volver a leer sobre JWT. Para verificar un token, necesita el secreto, y en su diseño, APP1 lo tiene, y debe tenerlo también en APP2 (exponiendo más riesgo) o confiar en APP1 para verificar el token en qué punto debe preguntar. usted mismo "¿Por qué le importaría a APP 1 si el token para APP 2 es válido? La respuesta es porque creó una dependencia innecesaria para que APP 1 sea responsable de la seguridad de APP 2.
2. Por la naturaleza de los tokens, no los maneja del lado del cliente, si un token no se actualiza, caduca, no sirve, debe negarlo. Se utiliza un token de actualización para generar un nuevo token de autenticación una vez que se alcanza su vencimiento. Un token de actualización de 30 minutos significa que después de 30 minutos debe volver a autenticarse completamente. Si ese era tu objetivo, entonces no tienes refrescos y tokens de autenticación de 30 minutos.
3. El propósito de un sistema de token es eliminar el estado de su aplicación. Si va a hacer sesiones, haga sesiones e ignore tokens. Si desea hacer contraseñas de un solo uso para la autenticación de la APP 2 que OTP, es horrible para ambos porque tiene todos los riesgos de ambos y no hay una buena razón para ambos. Me gustaría leer las sesiones frente a la autenticación de token.

Mi opinión sobre esto se basa en su pregunta: será una gestión de la seguridad, la administración de TI y la pesadilla de Dev Management que tendrá una aplicación independiente que confíe en otra aplicación independiente para los servicios de autenticación.

Estoy seguro de que hay más en la historia, pero si tomara una decisión al respecto, habría muchos "¿me explicarías por qué esto tiene sentido?" comentarios