React & Express JWT Auth: ¿Es lo suficientemente seguro almacenar tokens de acceso en cookies?

Pasé algunos días tratando de encontrar un método de autenticación seguro para SPA/React (lado del cliente).

La mayoría de los tutoriales que he leído en la naturaleza se contradicen entre sí.

Uno dice que tiene que almacenar en Cookies, otro en Almacenamiento local, uno dice que no necesita usar un token de actualización, uno dice que tiene que usar un token de actualización.

Estoy creando una aplicación React SPA para la interfaz y Express para la API (backend). Ambos se almacenan en el mismo dominio:

  • reaccionar :example.com
  • expreso : api.example.comoexample.com/api

¿Es suficiente para asegurar mi aplicación usando Cookie (token de acceso JWT):

  • httpSolo:✅
  • seguro: ✅
  • mismoSitio: strict
  • sin token de actualización

Esto coincide con la respuesta aquí: https://stackoverflow.com/a/57779076/11340631

La pregunta es:

  1. ¿Es esto lo suficientemente seguro?
  2. ¿Cuánto tiempo se tarda en establecer la caducidad del token de acceso?
  3. ¿Es esto según la recomendación de Oauth?: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps
  4. ¿Qué pasa si me roban mi token de acceso? Por ejemplo, mi amigo está usando mi PC y robó mis cookies y las usa en el navegador de su PC.

Realmente espero obtener la respuesta aquí, cualquier respuesta es apreciada.

Answer
  1. Es seguro contra la extracción del token con Cross Site-Scripting, pero, sin otros controles de seguridad, podría ser propenso a la falsificación de solicitudes entre sitios (las cookies se adjuntan automáticamente a una solicitud). ¿La API acepta la clave en la cookie o debe enviarse en el encabezado del Portador de autorización?

Mi preocupación es que, si no está utilizando un token de actualización, el token de acceso debe tener un vencimiento relativamente largo. OAuth2 no se diseñó para usarse solo para la autenticación, sino junto con alguna solución similar a una sesión, por ejemplo, OpenID Connect y SSO.

  1. Cuanto más corto, mejor, a menos que se pueda revocar en cualquier momento del lado del servidor. Si no hay forma de revocar la clave, la fecha de caducidad de 5 minutos es, en mi opinión, el máximo. Es por eso que el token de actualización y el punto final similar a una sesión son imprescindibles.

  2. OAuth no está diseñado para la autenticación de clientes de aplicaciones web. Ese es el antipatrón común en muchos proyectos que he probado. https://oauth.net/articles/authentication/

  3. Me alegro de que seas consciente de tal amenaza. Los tokens de acceso deben tener una vida muy breve o deben revocarse del lado del servidor de alguna manera, por ejemplo, utilizando algún tipo de lista de revocación. O se debe utilizar el token de actualización con un punto final de sesión similar al del servidor.

Nuevo colaborador
Malipek es un nuevo colaborador de este sitio. Tenga cuidado al pedir aclaraciones, comentar y responder. Consulta nuestro Código de Conducta .