Estoy tratando de descubrir la estrategia y los conceptos de autenticación correctos para una aplicación web de una sola página (SPA) con inicio de sesión local, así como inicio de sesión de terceros (por ejemplo, Google, Auth0). Desafortunadamente, una gran cantidad de artículos sobre el tema parecen interpretar mal los conceptos.
La idea básica es que el navegador y el servidor usarían un token de autenticación (por ejemplo, JWT), por lo que el servidor puede verificar si el usuario está conectado / autenticado.
Las preguntas y opiniones diferentes comienzan donde este token se debe almacenar en el navegador y cómo llega al servidor:
- En una cookie que usa HttpOnly (y preferiblemente segura, es decir, solo SSL): algunos artículos afirman que las cookies requieren estado del servidor y son de estilo antiguo, pero creo que están equivocadas aquí. Si la cookie era solo un ID de sesión, que el servidor necesitaría saber, entonces esto podría ser cierto, pero en los días modernos, la cookie es el token de autenticación, que el servidor solo puede verificar.
- PRO: llega al servidor sin JavaScript adicional del lado del cliente. Esto puede ser importante si utilizamos la representación del lado del servidor (SSR) para acelerar el rendimiento del SPA (por ejemplo, a través de Angular Universal)
- CON: vulnerable a XSRF / CSRF, pero hay soluciones para eso
- En LocalStorage / SessionStorage
- PRO: XSRF / CSRF no es un problema
- CON: vulnerable a XSS, pero hay correcciones para eso. El mayor problema puede ser que rompe el SSR, ya que para la solicitud inicial, no hay un JavaScript del lado del cliente que envíe el token
Mi preferencia es ligeramente hacia un token JWT almacenado como una cookie con alguna protección XSRF / CSRF agregada.
Esto se vería algo así (se omite XSRF aquí):
¿Meestoyperdiendoalgoaquí?
¿Cómofuncionaríaunaautenticaciónexternaconesto?Básicamente,estorequeriríaqueJavaScriptseejecuteenelcliente,redirigiraunformularioproporcionadoporelservidordetercerosyluegodequeelusuariohayaingresadoelnombredeusuarioylacontraseñaenelsitioexterno,elservidordeautenticacióndevuelveuntokenatravésdeJavaScript(básicamenteunadevolucióndellamada).¿Yahoraqué?
(Tengaencuentaquenocreequeseaunaopciónparaingresarelnombredeusuarioylacontraseña,enviarloamiservidorwebyelservidorwebsecomunicaconGoogle/Auth00.Estoesunno-go,yaquelosusuariosdeberíannoingresarsucontraseñaparaunsitiodetercerosenmisitioweb).
Eltokenquerecibodelsitioexternosepuedevalidar,sí,pero¿paraquésirve?
- ¿Seusaparaenviarsolicitudesdirectamenteamiservidor(reemplazandoeltoken/cookie)desdemiservidor?Esoromperíalaestrategiadelascookies,yaquenopuedoguardareltokenenelnavegador.
- seenvíaamiservidor(reemplazandoelnombredeusuario/contraseña)yelservidor,despuésdeverificarlo,devuelvesuJWTcomountoken.
Unavezmás,mipreferenciaesmáshacia2,peropuedoestarequivocadoaquí,opuedequeseapococomún(loqueesuninconvenienteencuestionesdeseguridad).Asísevería(denuevo,seomiteXSRF):
(No estoy seguro de si necesito almacenar el token externo).
¿Alguna idea u orientación?