Learn-json-web-tokens: Información peligrosa e incorrecta en README

Algunas preocupaciones muy bien pensadas y expresadas de manera articulada que ciertamente me están dando algo en que pensar como alguien que acaba de comenzar a mirar el repositorio. Estaba buscando un ejemplo rápido para crear un ejemplo de trabajo de autenticación JWT con Node. Mi interés en JWT es proporcionar un enfoque moderno de mejores prácticas para la administración de sesiones tanto para la API REST como para el cliente js mientras se evitan los problemas de CORS. Estoy un poco interesado en la seguridad, pero esta no es mi motivación para usar JWT, aunque aprecio el papel que pueden desempeñar los tokens en enfoques seguros más completos, como OAUTH. Cuando leí por primera vez este repositorio, me pareció que incluía muchas notas que el autor ha recopilado a medida que aumentan sus conocimientos sobre el uso de JWT, etc. Aunque tengo poca inversión en este repositorio, me inclino a creer que hay un lugar para un ejemplo de trabajo minimalista y específico de la plataforma de inicio de sesión / cierre de sesión con algunas herramientas de apoyo, referencias. Como base para las habilidades de incorporación y como principiante, creo que los objetivos de este repositorio son buenos, pero quizás el README necesite una reescritura seria y un reenfoque en los objetivos de este tipo de uso de JWT. Estaría feliz de intentar sugerir algo ... joepie91 - claramente tienes una buena comprensión de los problemas ... ¿podrías darnos algunas ideas sobre cuáles son realmente los beneficios reales de este tipo de uso de JWT?

Hola @ joepie91 , estamos _stoked_ que hayas encontrado y _leído_ nuestras notas sobre JWT!
gracias por tomarse el tiempo para abrir este número y plantear sus inquietudes. ❤️
Estaríamos _ encantados_ si dividiera cada una de sus inquietudes en un _ tema separado_ o al menos las enumerara para que sea más fácil discutirlas.

_Respetuosamente_ no estamos de acuerdo con que el contenido de estas notas sea "_Peligroso_".

_Cookies _> en el considerando 25 de la directiva de privacidad electrónica de la UE, cookies _ se mencionan explícitamente _ 5 veces:

ver:
https://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications#Cookies
o:
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX : 32002L0058: ES: HTML

Por supuesto, _muchos_ sitios web / aplicaciones (_ que no utilizan cookies de seguimiento de terceros_) caen bajo el ‘strictly necessary for the delivery of a service requested by the user’ ... por lo que _utilizamos_ cookies en nuestras aplicaciones web _ mejoradas progresivamente_. ver: https://github.com/dwyl/hapi-auth-jwt2#want -to-senttore-your-jwt-in-a-cookie

Almacenar JWT en _localStorage _> Si bien _ estamos de acuerdo_ en que almacenar datos / tokens de sesión en localStorage significa que se _requiere JavaScript _ (_ tampoco nos gusta esto, preferimos la mejora progresiva , esto tenía la intención de señalar una opción alternativa ..._). localStorage es cómo se crean _todas _ las aplicaciones creadas con un "_Backend-as-a-Service_", porque BaaS normalmente no acepta cookies ... ¿Está sugiriendo que medio millón de desarrolladores que utilizan Google Firebase Haciendolo mal_"...? (_ ¡Esta sería una gran discusión separada ...! _)

Las sesiones sin estado son _posibles_ con los JWT porque tienen una opción exp (_expiration time_) incorporada, sin embargo, _eligimos / preferimos_ _no _ convertir nuestras sesiones en apátridas en lugar de optar por almacenar una identificación de sesión ( jti ) _dentro_ el JWT que se busca en una tienda Redis _después de que se haya verificado el JWT. Esto significa que podemos _invalidar _ una sesión cuando una persona

Sí, el propósito _primario_ de los JWT es pass claims between parties in web application environment , eso es _exactamente_ para lo que los estamos usando.

Nuestros identificadores de sesión o tokens _podrían_ ser simplemente una cadena aleatoria que se verifica en el lado del servidor, pero _decidimos_ usar JWT para _formatear_ y _firmar_ los datos de la sesión.

Conclusión: actualice el archivo Léame para _clarify_ cosas. 👍

En lugar de dividir los problemas planteados en un conjunto de problemas como lo sugiere @nelsonic , tiendo a estar de acuerdo en que la intención y los objetivos de la implementación deben aclararse en el alcance del README. No leo los problemas de @ joepie91 como una crítica al uso de JWT en el contexto de aplicaciones web como tales, o el soporte de cookies como superior; más bien, considero que la crítica es que la descripción de JWT se presenta de una manera que superpone o tergiversa la razón para elegir JWT.
La misma preocupación se expresa también en el # 55 (aclarar que JWT no es encriptación ...)

Para mí, es suficiente poder operar Firebase y mis propios servicios usando un reclamo común que expira. Puedo extenderlo para incluir algún estado en algunos casos y no en otros y aún prefiero el enfoque al uso de cookies o enfoques de autenticación http de control de acceso más antiguos.
Me gusta que puedo usar tokens JWT como parte de un enfoque más sofisticado, pero aún estoy de acuerdo en que el enfoque en los beneficios del README debería estar en los problemas que buscamos resolver con ellos en lugar de desviarnos a un terreno menos sólido. Gran parte del material de referencia en el README tal vez podría relegarse a notas o incluso al Wiki como material de discusión.

No sé si diría necesariamente que el archivo README es peligroso, parece un poco fuerte

Cookies> en el considerando 25 de la directiva de privacidad electrónica de la UE, las cookies se mencionan explícitamente 5 veces:

Disculpas, parece que lo redacté de manera bastante vaga. Si bien el texto contiene la palabra "cookie" en varios lugares, no la identifica como un concepto específico a legislar; más bien, se proporciona como un ejemplo (y por lo tanto el resto de mi punto sigue siendo aplicable, y "no usar cookies" no eliminará mágicamente la necesidad de consentimiento).

localStorage es la forma en que se crean todas las aplicaciones creadas con un "Backend-as-a-Service", porque BaaS normalmente no acepta cookies ...

Esto es irrelevante y es un problema de esos servicios. Eso _no_ justifica el uso de JWT para sesiones en su propia aplicación.

¿Está sugiriendo que medio millón de desarrolladores que utilizan Google Firebase lo están haciendo "mal" ...?

Aparte del hecho de que Firebase está muy mal diseñado, esto es una apelación a la autoridad y no tiene lugar en una discusión técnica. No me interesa discutir las decisiones de una empresa en particular para un producto en particular; Solo me interesa discutir los méritos y las desventajas de un enfoque determinado.

Las sesiones sin estado son posibles con los JWT porque tienen una opción incorporada de exp (tiempo de vencimiento), sin embargo, elegimos / preferimos no convertir nuestras sesiones en apátridas en lugar de optar por almacenar una identificación de sesión (jti) dentro del JWT que se busca en un Redis se almacena después de que se haya verificado el JWT. Esto significa que podemos invalidar una sesión cuando una persona cierra la sesión o si su dispositivo es robado y necesita revocar una sesión activa.

En ese momento, ya no hay ningún beneficio real de usar JWT. ¿Por qué no está usando express-session o alguna otra solución de sesión revisada por pares y probada en batalla que se ajuste a su pila? La recomendación para JWT no tiene sentido aquí, porque las personas _no deberían estar implementando su propia administración de sesiones en primer lugar_.

Sin mencionar que el vencimiento de la sesión debe manejarse en el _server-side_, por lo que el exp en su JWT es esencialmente inútil.

Sí, el propósito principal de los JWT es pasar reclamos entre las partes en el entorno de la aplicación web, para eso es exactamente para lo que los estamos usando.

Los JWT no están relacionados con los "entornos de aplicaciones web" en lo más mínimo.

Nuestros identificadores de sesión o tokens podrían ser simplemente una cadena aleatoria que se verifica en el lado del servidor, pero decidimos usar JWT para formatear y firmar los datos de la sesión.

Nuevamente, solo use una implementación de sesión probada en batalla para su pila. JWT es una recomendación incorrecta para hacer aquí.

Respetuosamente no estamos de acuerdo con que el contenido de estas notas sea "peligroso".

Puede no estar de acuerdo, pero eso es lo que es. Hay tantas formas de usar JWT incorrectamente, varias de las cuales se mencionan en el archivo README en este repositorio, que la gente está _ atada_ a dispararse en el pie. Sí, es dañino.

@ pscott-au: joepie91 - claramente tiene una buena comprensión de los problemas ... ¿podría darnos algunas ideas sobre cuáles son realmente los beneficios reales de este tipo de uso de JWT?

No hay beneficios en el uso de JWT para aplicaciones web estándar, a menos que esté ejecutando a escala de Reddit. Algunos ejemplos comunes de casos en los que los JWT _son_ útiles:

• Mecanismos de inicio de sesión único (donde el JWT se utiliza como un token de autenticación de una sola vez que el usuario intercambia por una sesión en la aplicación de destino),
• Tokens de acceso temporal para imágenes privadas donde las URL están destinadas a ser compartidas,
• Básicamente, cualquier escenario en el que dos sistemas que confían entre sí necesitan intercambiar un poco de datos a través de una parte que no es de confianza, sin estar en contacto directo entre sí o compartir un backend.

Para las sesiones de aplicaciones web estándar, solo debe usar una implementación de sesión bien probada para cualquier pila que esté usando (por ejemplo, express-session cuando esté usando Express).

Es genial tener esta discusión, ya que realmente desafía parte de mi experiencia. Quizás algún contexto para mi interés personal en el uso de JWT (aparte del hecho de que hago uso de Firebase, que estaría interesado en aprender los problemas de ingeniería deficientes que analizaré). Al crear aplicaciones móviles / SPA y particularmente cuando utilizo servicios provenientes de múltiples servidores / dominios, encuentro que a menudo necesito una capacidad de inicio de sesión único a la que JWT parece prestarse muy bien. Tengo entendido que el uso de cookies de sesión evolucionó durante un período en el que se reforzó la seguridad en el navegador y el espacio JS y la introducción de CORS evolucionó para manejar las excepciones a esto, dejándonos con una solución bastante hacky que JWT va de alguna manera a abordar. .
Durante años, los enfoques de sesión de cookies ciertamente han brindado un enfoque mucho mejor que la autenticación http básica y resumida original y hay muchas veces en las que usaría una solución de administración de sesión de cookies para una aplicación basada en web.
Pero ... encuentro que la mayoría de las aplicaciones que estoy creando ahora son móviles o SPA y hacen un uso intensivo de REST APIS. Me gusta poder probar fácilmente con solicitudes simples de curl sin agrupar las cosas de manejo de cookies o lidiar con múltiples solicitudes para establecer la sesión. Así que me parece que la implementación rápida de las API hace que las cosas simplemente funcionen cuando uso JWT. En mi interior, se siente más apropiado usar JWT para sesiones de larga duración que las cookies, aunque reflexionaré sobre esto, ya que puede ser más pereza que buena intuición. Puedo extender la seguridad a lo largo de las líneas de OAUTH si es necesario y quiero asegurar las cosas de manera más completa, pero la mayoría de las veces la sesión no es algo que considero que necesita este nivel de seguridad. Lo importante para mí es la flexibilidad que ofrece un enfoque de autenticación basado en JWT con respecto a los cambios de arquitectura en el futuro. Descubrí que el código anterior se ha refactorizado para proporcionar la autenticación JWT como una opción y esto introdujo sorprendentemente poca complejidad de mantenimiento, pero en la mayoría de los casos optimizó el desarrollo futuro y no veo ninguna parte de él como inherentemente inferior a las sesiones de cookies.
De hecho, existen ventajas en el uso de las funciones de tiempo de espera de JWT, particularmente en dispositivos móviles y algunas bibliotecas de soporte hacen uso de esto. Por ejemplo, podría hacer que una aplicación cierre la sesión del usuario o dejarlo conectado en función de este tiempo de espera cuando el dispositivo no está conectado a la red.
Para mí, no veo ningún argumento convincente sobre las ventajas de escala de JWT sobre las cookies de sesión.
Veo personas que sugieren que JWT se puede usar como una cookie de sesión, lo que me hace más daño que bien, ya que las cookies tienen su propio período de tiempo de espera (no del lado del servidor completamente administrado) y es probable que la combinación de estos confunda.
Muchos marcos JS modernos brindan mayor soporte para JWT que para cookies, lo que sugiere que la solución revisada por pares para la pila, probada en batalla, puede de hecho tender hacia JWT para muchas aplicaciones. Si bien la popularidad de JWT para los servicios web no es un argumento técnico, descartar esto como irrelevante porque todos ellos es igualmente falaz. Express no es un elemento central de la pila utilizada por el grupo dwyl lo mejor que puedo decir, por lo que no hay razón para alinearse con él.
Espero que haya algún hilo de mi intención con el que pueda estar de acuerdo, ya que sigo preocupado pero no del todo convencido por sus argumentos.
Estoy de acuerdo en que el archivo README necesita una revisión seria y que hay líneas que persigue y que es mejor eliminarlas o colocarlas en un texto de discusión de fondo y no en el archivo README principal.

(aparte del hecho de que uso Firebase, me interesaría aprender los problemas de ingeniería deficientes que analizaré)

Algunos de los problemas son que su biblioteca cliente JS es de código cerrado y está ofuscada con una salida de error bastante inútil, no existen "matrices", hay muchos errores extraños en la biblioteca cliente en los que es posible que no obtenga una respuesta para Razones poco claras, el sistema ACL usa una variante JSON no estándar que incluso su propio editor no admite, la API JS requiere usar una API de pseudoeventos en lugar de una API de devolución de llamada normal (pero no se comporta de manera consistente), y pronto.

Al crear aplicaciones móviles / SPA y particularmente cuando utilizo servicios provenientes de múltiples servidores / dominios, encuentro que a menudo necesito una capacidad de inicio de sesión único a la que JWT parece prestarse muy bien. Tengo entendido que el uso de cookies de sesión evolucionó durante un período en el que se reforzó la seguridad en el navegador y el espacio JS y la introducción de CORS evolucionó para manejar las excepciones a esto, dejándonos con una solución bastante hacky que JWT va de alguna manera a abordar. .

No del todo exacto. Su aplicación y las API de terceros son cosas diferentes, con diferentes requisitos de autenticación. Mientras que un sistema de autenticación basado en tokens puede tener sentido en una aplicación cuando se habla con una API de terceros, esto no tiene sentido para su propia aplicación, incluso si es un SPA. Eso tampoco está relacionado con el "inicio de sesión único", que se refiere a varios servicios de usuario final que utilizan el mismo servicio de inicio de sesión.

CORS es un tema separado y no está realmente relacionado con esto.

Pero ... encuentro que la mayoría de las aplicaciones que estoy creando ahora son móviles o SPA y hacen un uso intensivo de REST APIS. Me gusta poder probar fácilmente con solicitudes simples de curl sin agrupar las cosas de manejo de cookies o lidiar con múltiples solicitudes para establecer la sesión. Así que me parece que la implementación rápida de las API hace que las cosas simplemente funcionen cuando uso JWT.

En desarrollo, es posible que tenga ciertos requisitos de prueba, pero estos no deberían afectar el enfoque que adopte en producción. Aparte del hecho de que la mayoría de las cosas que son un SPA realmente no deberían serlo para empezar (¡los SPA son para aplicaciones web, no para sitios web!), No hay ninguna razón por la que no pueda usar sesiones con ellos.

Aparte de eso, cURL admite cookies correctamente, y hay muchos otros clientes de prueba de API mejores como httpie o incluso http-prompt .

Puedo extender la seguridad a lo largo de las líneas de OAUTH si es necesario y quiero asegurar las cosas de manera más completa, pero la mayoría de las veces la sesión no es algo que considero que necesita este nivel de seguridad.

La sesión es uno de los aspectos más importantes de su aplicación. Si no es lo suficientemente segura, su aplicación está esencialmente rota y es completamente vulnerable. Por eso, por ejemplo. almacenar JWT en LocalStorage es una idea terrible.

Lo importante para mí es la flexibilidad que ofrece un enfoque de autenticación basado en JWT con respecto a los cambios de arquitectura en el futuro. Descubrí que el código anterior se ha refactorizado para proporcionar la autenticación JWT como una opción y esto introdujo sorprendentemente poca complejidad de mantenimiento, pero en la mayoría de los casos optimizó el desarrollo futuro y no veo ninguna parte de él como inherentemente inferior a las sesiones de cookies.

Aquí no se introduce ninguna flexibilidad que el 99,99% de los desarrolladores necesitarán alguna vez, y ya he destacado algunos de los problemas que presenta, como datos obsoletos e incapacidad para invalidar tokens.

De hecho, existen ventajas en el uso de las funciones de tiempo de espera de JWT, particularmente en dispositivos móviles y algunas bibliotecas de soporte hacen uso de esto. Por ejemplo, podría hacer que una aplicación cierre la sesión del usuario o dejarlo conectado en función de este tiempo de espera cuando el dispositivo no está conectado a la red.

Esto no es exclusivo de JWT; puede hacer esto con sesiones del lado del servidor sin problemas. De hecho, los JWT no se pueden invalidar sin introducir una arquitectura con estado (compleja), por lo que las sesiones realmente ganan aquí.

Para mí, no veo ningún argumento convincente sobre las ventajas de escala de JWT sobre las cookies de sesión.

La ventaja de la escala es que no necesita un solo servidor canónico que contenga todas las sesiones (ya que los datos se pueden almacenar directamente en el token), lo que significa que puede eliminar un cuello de botella. Pero como dije, casi ningún desarrollador se encontrará con este problema en la práctica. Solo es útil para proyectos de gran escala.

Muchos marcos JS modernos brindan mayor soporte para JWT que para cookies, lo que sugiere que la solución revisada por pares para la pila, probada en batalla, puede de hecho tender hacia JWT para muchas aplicaciones.

Todavía tengo que ver un marco que no admita cookies de sesión.

Express no es un elemento central de la pila utilizada por el grupo dwyl lo mejor que puedo decir, por lo que no hay razón para alinearse con él.

Ese es su problema. Express fue simplemente un ejemplo, existen implementaciones de sesión bien probadas para básicamente todos los marcos de uso común.

La conclusión es que para cualquier desarrollador que esté leyendo este repositorio, JWT tendrá exactamente cero ventajas en el mundo real y varios inconvenientes o incluso problemas de seguridad. Simplemente no es una buena elección técnica o recomendación, y ese es realmente el final.

@ joepie91 ¡ No puedo decirte lo _ encantado_ que estoy de que hayas encontrado nuestro repositorio / notas y hayas invertido tu tiempo para leerlo y darnos tu opinión! En serio, si alguna vez te conozco en persona, ¡te daré una paleta de lo que sea que te guste beber! 🍺

Si te convierto en colaborador de este repositorio, ¿revisarás mi Pull Request para _ mejorarlo_? 📝

Además, @AshleyPinner , @alfiepates , @ sunny-g, ¿cómo se

He estado masticando esto durante un par de días y simplemente no puedo sumarme a muchos de los argumentos en contra del uso de JWT como una opción predeterminada antes de las cookies de sesión tradicionales en las aplicaciones móviles y SPA modernas.
Estaba pensando en construir una matriz de decisiones para sopesar los pros y los contras de los enfoques de autenticación de cookies / JWT para requisitos específicos, o detallar los pros y los contras en un conjunto de casos de uso antes de pensar en reescribir el archivo README. Me parece que muchos de los desafíos del mundo real que enfrentan las personas al crear aplicaciones complejas se resuelven en su mayor parte con menos elegancia o al menos tan problemáticos al usar sesiones de cookies. La percepción que crea el póster problemático es que JWT es una tecnología inmadura poco confiable pirateada que no es adecuada para aplicaciones modernas y esta afirmación es quizás incluso más peligrosa que proporcionar un ejemplo completamente trabajado de su uso para autenticar a un usuario.
Encontré útil este artículo de OATH . Creo que una de las cosas que ha desencadenado una reacción tan fuerte a este repositorio, pero el informador del problema es la discusión de las características que normalmente se esperan en las sesiones de cookies que usan JWT que restan valor a algunos de los beneficios principales de JWT, principalmente que lo involucran. puede ser apátrida. Al introducir el estado mediante la incorporación de almacenamiento persistente, estamos eliminando uno de los principales casos de uso de JWT y volviendo a implementar las cosas que están maduras con el uso de cookies.
Dicho esto, las aplicaciones complejas son propensas a requerir algún hallazgo de estado, incluso si solo se trata de solicitudes transaccionales de acciones que se procesan más allá de la vida de una sola solicitud HTTP. Esto no debería excluir el uso de JWT, pero debería darnos una pausa para considerar qué papel juega el JWT en la transacción. Considero que está bien tener un JWT que otorga acceso a un recurso y el recurso tiene un estado para el usuario que niega el acceso a un servicio; en este caso, no es el JWT el que debe caducar, sino el estado del usuario que accede al servicio mediante el JWT.

Ampliar aún más el uso de cookies como mecanismo de transporte elimina otro de los beneficios y nos devuelve a usar cookies, pero ignorando la funcionalidad habitual de la biblioteca y reescribiendo las características desde cero, lo que introduce una mayor ambigüedad porque terminamos con tiempos de espera duplicados, etc. Cuando mencioné CORS anteriormente tal vez sea mejor ser explícito al señalar las dificultades de usar múltiples dominios con cookies. Claro, puede configurar dominios comodín, pero si son lo suficientemente diferentes, las cookies de sesión tradicionales se vuelven rápidamente difíciles de manejar. Se puede argumentar que la mayoría de los desarrolladores no necesitan su cliente autenticado para acceder a recursos protegidos en múltiples dominios, pero esto se está convirtiendo en una práctica mucho más común que en un caso extremo exótico.
En cierto sentido, como una persona nueva que comienza a explorar la administración de sesiones autenticadas, aprecio que esta puede no ser una forma adecuada de aprender cómo limitar el acceso a un recurso en una aplicación web a usuarios autenticados en el sentido más simple, pero el uso de JWT solo se volverá más prominente como el punto de partida para las sesiones autenticadas, por lo que descartar esto porque hemos usado cookies de sesión durante mucho tiempo no es suficiente para creer que todos deberían comenzar con cookies de sesión y solo aprender y usar JWT cuando descubren que no pueden compartir cookies entre dominios o necesitan acceder a una API de terceros o necesitan poder determinar la caducidad sin verificar el servidor, o cuestionar el almacenamiento de las credenciales de inicio de sesión del usuario en el dispositivo móvil, etc., etc. .

Subestimar las ventajas de los tokens sin estado como algo irrelevante a menos que esté ejecutando un sitio con tráfico de primer nivel es incorrecto. Incluso cuando mejoramos las cosas introduciendo una nueva capa de estado, el desacoplamiento de la sesión del servidor tiene numerosas ventajas.

@nelsonic Mirando 4744cd1bb8991bc4057c749f86007fcecac19d1d, parece una redacción mucho más clara. Sin embargo, el encabezado no parece reflejar los cambios.

@ pscott-au: en SPA modernas y aplicaciones móviles.

Esto es _completamente_ ortogonal a su elección de mecanismo de sesión. Sin mencionar que la mayoría de las cosas que son un SPA hoy en día, no deberían serlo. El uso de un SPA para un sitio web (a diferencia de una aplicación web) rompe la web.

Me parece que muchos de los desafíos del mundo real que enfrentan las personas al crear aplicaciones complejas se resuelven en su mayor parte con menos elegancia o al menos tan problemáticos al usar sesiones de cookies.

¿Tal como?

La percepción que crea el póster problemático es que JWT es una tecnología inmadura poco confiable pirateada que no es adecuada para aplicaciones modernas.

No, no lo es. JWT como tecnología no es terrible (incluso si _hay_ algunas decisiones cuestionables en la especificación) - las sesiones simplemente no son su propósito previsto, y no se ajustan bien a ese caso de uso.

No estoy diciendo que la herramienta sea mala, estoy diciendo que la estás usando mal.

y esta afirmación es quizás incluso más peligrosa que

¿Cuál es su razón de ser para eso?

Encontré útil este artículo de OATH.

Abordarlo punto por punto:

• Sin estado, escalable y desacoplado: ya he reconocido que este es un beneficio teórico, pero que en la práctica casi nadie realmente necesita. También debe considerar que Auth0 tiene un interés personal aquí, uno que _no_ lo beneficia como desarrollador: _ "Los servicios de terceros como Auth0 pueden manejar la emisión de tokens y luego el servidor solo necesita verificar la validez del token. "_ Por cierto, subcontratar su autenticación es una idea _terrible_.
• Cross Domain y CORS: completa y absoluta tontería. Esto habla del _método de almacenamiento_, que es completamente independiente de si el token _contiene_ los datos de la sesión o no. Puede hacer que se envíe una ID de sesión manualmente o puede almacenar un JWT en una cookie. No tiene nada que ver con JWT versus sesiones, lo que también muestra el sesgo / ignorancia del autor del artículo, ya que comparar "cookies versus tokens" _no tiene ningún sentido para empezar_. También ignora por completo este problema de seguridad .
• Almacenar datos en el JWT: no es una función. Lo mismo se aplica a las sesiones. Y galletas, por cierto.
• Rendimiento: esto es solo una repetición del punto "sin estado", en su mayoría, aparte del hecho de que no está _en absoluto_ claro si la verificación criptográfica puede necesariamente vencer a algo como Redis en el rendimiento del manejo de datos de sesión (su comparación con un RDBMS no es realista) , también es una optimización de rendimiento completamente insignificante para casi todas las aplicaciones web. Esto se denomina "optimización prematura" y se recomienda ampliamente por muy buenas razones.
• Listo para dispositivos móviles: tonterías. Si su biblioteca HTTP no admite cookies, _ busque una biblioteca HTTP mejor_. Las cookies son compatibles, son solo encabezados HTTP.

Así que no, ese artículo no aporta ningún beneficio nuevo de JWT que aún no haya cubierto. Simplemente tergiversa el beneficio a veces (apatridia) como algo que se aplica a todas las aplicaciones (no lo hace), y luego hace comparaciones sin sentido y enfatiza demasiado el rendimiento de la sesión para el resto.

Creo que una de las cosas que ha desencadenado una reacción tan fuerte a este repositorio, pero el informador del problema es la discusión de las características que normalmente se esperan en las sesiones de cookies que usan JWT que restan valor a algunos de los beneficios principales de JWT, principalmente que lo involucran. puede ser apátrida.

Como he dicho, esto casi nunca es un beneficio en la práctica. Puede seguir repitiendo este mismo punto de apatridia una y otra vez, pero no lo hará más válido o aplicable. Absolutamente no es un requisito de propósito general.

Considero que está bien tener un JWT que otorga acceso a un recurso y el recurso tiene un estado para el usuario que niega el acceso a un servicio; en este caso, no es el JWT el que debe caducar, sino el estado del usuario que accede al servicio mediante el JWT.

En cuyo caso, no tiene precisamente ningún beneficio sobre un ID de sesión normal de algún tipo.

[...] Cuando mencioné CORS anteriormente, quizás era mejor ser explícito al señalar las dificultades de usar múltiples dominios con cookies. Claro, puede configurar dominios comodín, pero si son lo suficientemente diferentes, las cookies de sesión tradicionales se vuelven rápidamente difíciles de manejar.

Esto también es completamente ortogonal al punto. Se trata únicamente de dónde _ almacena_ sus identificadores, no de si _contienen_ los datos de la sesión por sí mismos. Y nuevamente, riesgo de seguridad .

pero el uso de JWT solo se volverá más prominente como punto de partida para las sesiones autenticadas

Y eso me preocupa mucho, porque ese uso prominente se basa en la ignorancia y la exageración, y conlleva muchos problemas de seguridad. Este es un gran paso atrás.

para descartar esto porque hemos utilizado cookies de sesión durante mucho tiempo

Nunca dije nada por el estilo. He proporcionado varias razones _muy_ claras de por qué JWT es _objetivamente inferior_ para la gestión de sesiones.

y solo aprenden y usan JWT cuando descubren que no pueden compartir cookies entre dominios

En cuyo caso, problema de seguridad . Las cookies _no son opcionales_.

o necesita acceder a una API de terceros

Irrelevante para las sesiones.

o necesita poder determinar la caducidad sin verificar el servidor

No es posible, porque el servidor necesita conservar la capacidad de invalidar explícitamente una sesión, por ejemplo. cuando el usuario cambia su contraseña o cierra por la fuerza otras sesiones.

o cuestionar el almacenamiento de las credenciales de inicio de sesión del usuario en el dispositivo móvil, etc., etc.

Galletas. Hecho.

Subestimar las ventajas de los tokens sin estado como algo irrelevante a menos que esté ejecutando un sitio con tráfico de primer nivel es incorrecto. Incluso cuando mejoramos las cosas introduciendo una nueva capa de estado, el desacoplamiento de la sesión del servidor tiene numerosas ventajas.

Sin embargo, no mencionas ninguno de ellos que no haya abordado y tenido en cuenta en mis conclusiones. Lo siento, pero usted defiende enfoques novedosos en aras de ser enfoques novedosos e ignora por completo las _propiedades objetivas y técnicas_ de los diferentes enfoques.

Eso es lo que se llama "exageración" y es extremadamente dañino.

Sin estado: importante cuando una aplicación necesita funcionar sin conexión y conservar algún tipo de significado.

Las aplicaciones sin conexión no necesitan autenticación, _en absoluto_. Por definición, no hay interacción con otros sistemas.

Autenticación de credenciales de dominio cruzado: importante si divide su aplicación en microservicios utilizando varios servidores

Correcto. Pero en este caso, no usa JWT _como su mecanismo de sesión_, lo usa como un token de un solo uso que se puede _cambiar_ para una sesión. Hay una gran diferencia entre los dos y las compensaciones que presenta.

( EDITAR: Por supuesto, esto asume microservicios _stateful_, y con 'stateful' no me refiero a la sesión, sino al servicio en sí. Para microservicios que llevan a cabo tareas sin estado, tokens de un solo uso _sin_ usar una sesión es suficiente, con los tokens de un solo uso emitidos por el servidor de aplicaciones. Para los servidores de aplicaciones que hablan con microservicios, JWT también está bien: aquí no existe el concepto de una "sesión", y la revocación del token se puede realizar cambiando la clave de firma).

Puede continuar negando la utilidad de JWT

Una vez más, no estoy haciendo tal cosa. Estas son enteramente tus palabras.

Cuando trato de proporcionar más detalles, simplemente descarta mis casos como irrelevantes o como una mala práctica ... en mi opinión, incorrectamente.

Entonces espero que explique _por qué_ es incorrecto, no solo diga "¡eso es incorrecto!" y espere que me lo tome al pie de la letra. Me estoy refiriendo concretamente a cada punto que proporcionas precisamente por esta razón.

Depender de una cookie para administrar una sesión de inicio de sesión de iOS no es la mejor solución por defecto.

¿Por qué?

las cookies se pueden usar incorrectamente

Esa es una declaración vacía. _¿Cómo_ mal utilizado? ¿Y cómo no se aplica esto a los valores almacenados en el almacenamiento local? ¿Y qué tiene esto que ver con JWT _en absoluto_ dado que las "cookies" son un método de almacenamiento, no un mecanismo de sesión? Comparar "JWT vs. galletas" es comparar manzanas y naranjas, ¡ni siquiera son la misma clase de cosas!

El uso de JWT para la gestión de sesiones es diferente y tiene propiedades diferentes a las sesiones de cookies; esto no lo hace inferior, sino que simplemente tiene diferentes criterios de parámetros operativos para diseñar una solución adecuada. Si desea utilizar cookies, utilice cookies, si cumplen con sus requisitos, utilícelas, ¿por qué quiere evitar que otras personas consideren cualquier otro enfoque?

No soy. He _muy claramente_ indicadas excepciones en las que JWT _es_ la solución correcta. También he indicado _ muy claramente_ que JWT no es adecuado como mecanismo de sesión de propósito general . Dejar de poner palabras en mi boca.

Su idea de que las sesiones de inicio de sesión son valiosas solo para autenticarse contra su servidor web con almacenamiento persistente ignora el hecho de que es posible que desee que algunos servicios de datos proporcionados por proveedores alternativos validen el mismo JWT y no requieran la creación de nuevas cookies. . ¿De qué manera esto es irrelevante para las sesiones ???

Porque no hay ninguna razón por la que no pueda usar _tanto_ JWT como sesiones, para diferentes propósitos. Tratar de calzarlo todo en un solo mecanismo por el simple hecho de hacerlo es _completamente_ equivocado. Utilice la herramienta que sea apropiada - "no requerir que se creen nuevas cookies" es una métrica completamente arbitraria y realista, no el beneficio que usted está insinuando que es.

Si ve problemas de seguridad, identifíquelos y márquelos; es posible que no sean un obstáculo, pero puede ser útil tenerlos en cuenta al tomar la decisión. Su redacción virulenta no reconoce esto o incluso considera que esto es una posibilidad porque continúa afirmando que las cookies de sesión deben usarse para cada aplicación http, lo cual es simplemente ridículo.

De nuevo. No. Yo dije. Deja de poner palabras en mi boca.

Los ejemplos que citó sobre la función de las sesiones para hacer cumplir reglas específicas, como la terminación de cambios de contraseña o para administrar restricciones de servicio, no es una función incorporada de las cookies de sesión, solo una función que normalmente se utiliza en este enfoque.

Es una característica que _requiere_ sesiones con estado de algún tipo, arquitectónicamente. No estoy argumentando que esto sea proporcionado por cookies de sesión, estoy argumentando que es _imposible_ con tokens sin estado.

Si su solución es bastante cómoda para proporcionar acceso autenticado sin verificar una base de datos para acceder a un recurso durante la vida útil de la sesión, entonces ¿por qué insiste en que esto es un fracaso de este enfoque?

De nuevo, no lo que dije.

Cuando sugerimos que los controles específicos (en caso de que requieran algún tipo de sesión terminable) podrían introducirse según sea necesario, responde que las cookies tienen esto incorporado y que nunca debe intentar buscar otros enfoques. La implementación de este tipo de control no supone una sobrecarga tan significativa como para excluir las sesiones de autenticación de JWT sobre las cookies.

El punto no es por encima de la cabeza. El punto es utilizar soluciones probadas y comprobadas que se sabe que funcionan bien . Reimplementar su propia seguridad es una idea terrible en _ cualquier_ situación, y eso incluye esta.

Ignora el número de solicitudes de cookies y sugiere que la única consideración de rendimiento es la búsqueda. La necesidad de coordinar actualizaciones, etc. y depende de ... oh no importa ... (se dio por vencido aquí)

¿De qué estás hablando? Las "actualizaciones" de cookies se manejan en línea en las respuestas HTTP mediante el envío de una nueva cookie; aquí no hay nada adicional aparte de actualizar el almacén de sesiones, que ya he cubierto en mi ejemplo de Redis. Si cree que hay otras consideraciones de rendimiento, _lístalas_.

Puede que le guste que las cookies estén restringidas a dominios y considere que permitir su uso entre dominios introduce problemas de seguridad que impiden su uso, eso está bien, yo no.

De nuevo, no lo que dije.

JWT no es lo siguiente en reemplazar todas las cookies de sesión, pero tampoco son una abominación tan seria (cuando se usan para administrar sesiones) como usted indica.

Sí lo son. La única razón por la que alguna vez querría usar JWT para las sesiones es porque las alternativas son peores o imposibles, y ese es un caso extremo _extremadamente_ raro.

Trata la seguridad como un absoluto sin mencionar las diversas mejoras que se podrían hacer a este enfoque cuando sea necesario y cómo la complejidad de esa evolución se compara con los enfoques tradicionales basados ​​en sesiones.

Solo trato la seguridad como un absoluto cuando _es_ un absoluto. También he abordado las posibles formas de resolverlo, y he explicado cómo no son una buena solución en comparación con las sesiones porque el resultado neto es aún peor. Si cree que hay un caso o una solución que me falta, menciónelo. Deje de aludir vagamente a "otras opciones" sin explicar realmente cuáles son. En este momento, por lo que puedo decir, estás fanfarroneando.

No es una exageración: no se basa en la ignorancia, pero es una solución válida para los problemas que se enfrentan regularmente al crear aplicaciones híbridas que requieren autenticación cruzada para servicios que no tienen como objetivo proporcionar la seguridad más estricta que la tecnología puede ofrecer y, por una buena razón, muy práctica, de manera muy amplia. adoptado - no hace que todo se convierta en una mierda.

Repetir tu afirmación no la hace más cierta. Ya he explicado por qué esto es falso, y no es aceptable comprometer la seguridad por razones exageradas.

Para algunos de nosotros, tener la flexibilidad de controlar la sesión con una granularidad más fina que la proporcionada por las cookies ofrece una mayor flexibilidad; si no ve los casos de uso, entonces está bien; espero que si crea muchas aplicaciones híbridas, lo hará y tal vez luego Podrá articular mejor los contraargumentos a algunos de los puntos que presenta que yo.

No hay una "mayor flexibilidad". Nuevamente, si cree que sí, explique cómo.

De todos modos, eres mucho más elocuente que yo y claramente eres inquebrantable en tu posición.

No. Solo espero que alguien proporcione argumentos sólidos, bien argumentados y técnicamente correctos, si desea cambiar mis puntos de vista. No lo has hecho.

Recuerdo que la última vez que tuve un apego tan implacable a un enfoque fue cuando alguien argumentó que la autenticación de resumen nunca debería reemplazarse con cookies de sesión.

... y ese sería un ejemplo perfecto de tal falacia.

La conclusión es que la mitad de sus declaraciones están poniendo palabras en mi boca que nunca he pronunciado, ni implícito ni pretendido. La otra mitad aboga por un compromiso innecesario en la seguridad, o hace afirmaciones onduladas sobre la existencia de "otros beneficios" u "otras soluciones" sin siquiera profundizar en el tema.

Francamente, estoy cansado de esto, no creo que esta discusión vaya en una dirección constructiva y está enturbiando el hilo. La única razón por la que sigo respondiendo es por el riesgo de que las personas se desinforman con sus no argumentos.

Si quiere seguir creyendo que JWT es el santo grial a pesar de no tener argumentos técnicos para respaldar esa noción, entonces esa es su elección, pero no me convencerá a menos que presente argumentos técnicos reales y continúe repitiendo las mismas afirmaciones sobre y otra vez no va a ayudar a nadie.

Para resumir mis puntos para aquellos que leen toda la discusión:

• JWT no está diseñado para sesiones, sino para transferir reclamos firmados, generalmente de un solo uso.
• JWT no es adecuado para sesiones debido a la incapacidad de invalidar tokens, problemas con datos obsoletos y la necesidad de escribir implementaciones no probadas para que funcione. Estos son problemas de seguridad.
• "Cookies vs. JWT" no es una comparación válida; uno es un mecanismo de almacenamiento mientras que el otro es un formato de token. Las cookies no son
• A veces, no puede usar sesiones con estado porque está operando a una escala muy grande y, en esos casos, JWT puede ser la opción 'menos mala' disponible, pero estos casos son raros y, a menos que trabaje para un sitio importante del tamaño de Reddit, es probable que nunca te encuentres con ellos.

(Por cierto, Reddit usa sesiones con estado).

Creo que la intención de este repositorio es allanar el camino para la implementación de un SPA híbrido móvil y el uso de JWT como reemplazo de las sesiones de cookies es un enfoque común y casi estándar.
Uno de los impulsores de esto es el problema que tienen las cookies al estar vinculadas a un dominio cuando un SPA puede, de hecho, requerir acceso a microservicios en múltiples dominios en diferentes plataformas. JWT es un enfoque claro de las limitaciones de las cookies en este contexto. El uso de un enfoque OAUTH o OAUTH2 sería más sólido desde el punto de vista de la seguridad, pero introduce una complejidad que puede no ser necesaria para muchas aplicaciones. Las sesiones de portador de JWT que no dependen de la negociación de un token AUTH no son un mal uso de JWT, sino una aplicación de un enfoque menos seguro para ganar simplicidad y para aplicaciones que tienen más que ganar con una implementación rápida que la seguridad adicional proporcionada por un más enfoque robusto. Al mismo tiempo que agiliza la implementación rápida, proporciona una ruta de migración más clara a tokens de un solo uso que a otros enfoques.
Parte de la reacción y el vitriolo contra el uso de encabezados de token de portador de JWT como reemplazo de las cookies de sesión se basa en que algunas personas los presentan como una evolución o mejora de las cookies en general, lo cual estoy de acuerdo en que no es el caso. Le pido que considere así mis casos de uso y cómo los abordaría utilizando cookies.
El uso de JWT para la gestión de sesiones de autenticación debe hacerse con cuidado y las deficiencias deben hacerse explícitas, sin embargo, descartarlas como exageraciones inútiles que siempre se usan fuera de contexto es engañoso e incorrecto.
El uso de JWT significa que no es necesario actualizar las cookies cada vez que el cliente contacta con el servidor. Puede garantizarse una confianza razonable sin comprobar la base de datos, aunque es tan fácil ampliar esta comprobación como utilizar cookies de sesión.
El uso de JWT significa que los clientes con cookies bloqueadas no se verán obligados a recurrir al uso de variables de publicación ocultas, etc., como reabastecimiento.
El uso de JWT en varios servicios permite un servicio que no requiere autenticación, pero quiere alguna indicación de la validez de un campo de datos simple, como uid, que se puede envolver en un JWT y pasar.
Los enfoques de JWT se prestan a enfoques OAUTH más sofisticados.
Las solicitudes de JWT REST se pueden realizar sin publicar credenciales o sin requerir una solicitud de una cookie antes de acceder al servicio, lo que puede simplificar la implementación de REST / SPA.
El uso de un encabezado de portador o un encabezado de cookie no es dramáticamente diferente cuando se trata de seguridad (a excepción de las restricciones de dominio que pueden ser válidamente indeseables. la seguridad es peor)
Cuando los períodos de ausencia prolongados son comunes / esperados, como con las aplicaciones móviles, las cookies pueden ser menos deseables que un enfoque de JWT. Tener un camino más claro para el autoexamen de credenciales puede facilitar el comportamiento sin registrarse con el servidor.
Si acepta que hay casos de uso para sesiones que pueden tener períodos prolongados fuera de línea, las sesiones no son necesariamente con estado.
Si puede aceptar que las sesiones pueden existir con éxito con varios estados desde la perspectiva del cliente y el servidor, tal vez pueda acercarse a los casos de uso que incluyen períodos de no conectividad prolongada con el servidor (por ejemplo, recopilar datos del usuario para la actualización por lotes al volver a conectar). Hay casos en los que el cliente podría operar de manera más efectiva sabiendo que la sesión ha expirado y se requiere una actualización sin administrar otra capa de datos. Además, poder usar el JWT como validación de sesión incluso después de que la contraseña haya cambiado, etc., puede ser útil en algunos casos para permitir que los datos se pasen a la capa de lógica empresarial y que ellos decidan cómo aceptar la solicitud.
Me sigue diciendo que las cookies son seguras, lo que supongo que alude a la implementación en los navegadores, etc., fuera de un navegador, no veo por qué son intrínsecamente más seguras, ¿tal vez pueda explicarlo?
En las aplicaciones SPA / híbridas, la dependencia de las cookies no es necesariamente la única posición de partida: confiar en el manejo de las cookies por parte del navegador no lo acerca a las aplicaciones nativas, pero introduce una dependencia de UIWebView o lo que sea y no estoy seguro de que siempre lo hará. comportarse como espero.
Los tokens se pueden retener en la memoria durante la ejecución de una aplicación sin que necesariamente se conserven; esto no es realmente lo mismo que confiar en la integridad de las cookies; hay un control más granular en iOS, al menos en los permisos de almacenamiento que existen más allá del navegador. y esto me parece más apropiado que estar atado a los enfoques de almacenamiento del navegador.
Las cookies son de hecho opcionales; no existe ninguna ley que indique que solo debe utilizar cookies.
En algunos casos, el desacoplamiento de la sesión del servidor puede ser algo malo, pero no siempre: los enfoques modernos, incluido el uso de JWT, introducen nuevas preocupaciones, pero también una nueva flexibilidad, y esta flexibilidad no solo incluye los enfoques menos malos.

Para resumir mi posición:
El uso de JWT como parte de una solución de sesión de autenticación no siempre es superado por las cookies de sesión.
JWT es adecuado para la sesión si conoce los beneficios y tiene una razón para no requerir una invalidación simplista.
Las cookies no son la única solución.
La gran escala no es el único caso de uso para sesiones sin estado: el uso de encabezados JWT para autenticarse en dominios / servicios es una razón válida para usarlos como alternativa a las cookies de sesión.

Le pido que considere así mis casos de uso y cómo los abordaría utilizando cookies.

Seguro.

El uso de JWT significa que no es necesario actualizar las cookies cada vez que el cliente contacta con el servidor.

Esto es lo mismo para las cookies de sesión, las cookies que contienen JWT, los tokens _y_ JWT en sí mismos; solo necesita 'actualizarlos' explícitamente si están a punto de caducar. Aquí no hay diferencia.

El uso de JWT significa que los clientes con cookies bloqueadas no se verán obligados a recurrir al uso de variables de publicación ocultas, etc., como reabastecimiento.

Es casi seguro que los usuarios que bloquean las cookies también bloquearán el almacenamiento local y otras medidas de persistencia (precisamente por la misma razón por la que bloquean las cookies). Las extensiones de privacidad hacen lo mismo. Nuevamente, "JWT vs. cookies" _no es una comparación válida_, y si un usuario bloquea las cookies, no podrá conservar un token _ de todos modos_. JWT o no, no importa.

(Si un usuario bloquea las cookies al por mayor, ya elige no tener persistencia de datos de todos modos, por lo que tratar de admitir la autenticación para los usuarios que bloquean las cookies es una causa perdida. Esa es la compensación que viene con esto, y es una solución completamente razonable desde el punto de vista técnico. compensación.)

El uso de JWT en varios servicios permite un servicio que no requiere autenticación, pero quiere alguna indicación de la validez de un campo de datos simple, como uid, que se puede envolver en un JWT y pasar.

Vea la edición de mi publicación anterior (tercer párrafo), que aborda los tokens de un solo uso en arquitecturas distribuidas. Estas no son sesiones ni deben ser persistentes, por lo que los problemas que he descrito no se aplican allí.

Los enfoques de JWT se prestan a enfoques OAUTH más sofisticados.

OAuth utiliza tokens de un solo uso. No reemplaza las sesiones. Nuevamente, vea la edición de mi publicación anterior.

Las solicitudes de JWT REST se pueden realizar sin publicar credenciales o sin requerir una solicitud de una cookie antes de acceder al servicio, lo que puede simplificar la implementación de REST / SPA.

No pueden. Aún necesita obtener un JWT _ de alguna manera_, lo que significa que debe ser emitido por el servidor, lo que significa que debe solicitarlo al servidor. No importa si el servidor devuelve una cookie o un encabezado o valor diferente. Y nuevamente, "cookies vs. JWT" no es una comparación válida.

El uso de un encabezado de portador o un encabezado de cookie no es dramáticamente diferente cuando se trata de seguridad (excepto por las restricciones de dominio que pueden ser válidamente indeseables.

No veo una discusión aquí.

Cuando los períodos de ausencia prolongados son comunes / esperados, como con las aplicaciones móviles, las cookies pueden ser menos deseables que un enfoque de JWT. Tener un camino más claro para el autoexamen de credenciales puede facilitar el comportamiento sin registrarse con el servidor.

Esto no es un beneficio: no _necesita_ el token hasta que tenga la intención de comunicarse con un servidor de todos modos, por lo que puede intentar hacer una solicitud y lidiar con el 403 cuando suceda. Tratar de evitar pedirle al servidor algo que inherentemente implica hablar con un servidor (es decir, realizar una solicitud autenticada) no tiene sentido.

Sin mencionar que, si desea saber con anticipación si su sesión habrá expirado, puede enviar una cookie separada para esto. Dado que es solo una sugerencia de UX para la aplicación, ni siquiera necesita verificar su autenticidad, y debe lidiar con fallas de autenticación inesperadas _ de todos modos_ debido a la desviación del reloj y las claves de firma cambiadas.

En las aplicaciones SPA / híbridas, la dependencia de las cookies no es necesariamente la única posición de partida: confiar en el manejo de las cookies por parte del navegador no lo acerca a las aplicaciones nativas, pero introduce una dependencia de UIWebView o lo que sea y no estoy seguro de que siempre lo hará. comportarse como espero.

No es así. Cualquier biblioteca HTTP razonable, navegador o no, admitirá cookies. Las cookies son _de ningún modo_ exclusivas de los navegadores, son una función HTTP como cualquier otra.

En algunos casos, el desacoplamiento de la sesión del servidor puede ser algo malo, pero no siempre: los enfoques modernos, incluido el uso de JWT, introducen nuevas preocupaciones, pero también una nueva flexibilidad, y esta flexibilidad no solo incluye los enfoques menos malos.

Todavía no he visto ningún ejemplo concreto de tal "flexibilidad".

El uso de JWT como parte de una solución de sesión no siempre es superado por las cookies de sesión.

Esa es una declaración muy ambigua. Está comparando el uso de JWT como parte de la solución con el uso de cookies de sesión como solución completa. Estos no son opuestos: muchas arquitecturas complejas requerirán una combinación de cookies de sesión y tokens JWT de un solo uso, por ejemplo, para sistemas SSO o arquitecturas distribuidas.

JWT es adecuado para la sesión si conoce los beneficios y tiene una razón para no requerir una invalidación simplista.

No. Los tokens JWT son un _ último recurso_ cuando no puede cumplir con los requisitos con las cookies de sesión.

Las cookies no son la única solución.

Técnicamente correcto.

La gran escala no es el único caso de uso de sesiones sin estado.

Es _es_ el único caso de uso que conozco, y no he visto ningún otro válido mencionado a lo largo de este hilo. Tenga en cuenta que estoy hablando específicamente de _sesiones_ sin estado_, no de tokens sin estado _ en general_.

Les pregunto esto: ¿cómo implemento una aplicación que utiliza 3 servicios diferentes (tal vez en una infraestructura de contenedores diferente, etc.) y los integro en la aplicación confiando en las cookies de sesión? Si configuro un servicio de autenticación y deseo desvincularlo de otro servicio, ¿cuál es el mejor enfoque para ejecutar un controlador de sesión de cookies de proxy compartido? ¿Es este un caso marginal?
¿Cómo las cookies me brindan mayor seguridad, flexibilidad y cumplimiento de estándares que usar un JWT de larga duración para rastrear mi sesión? Suponiendo que no quiero ni me importa poder terminar la sesión a pedido (aunque eso no es exactamente un beneficio inherente de las cookies, sino más bien en el manejo de solicitudes), que estoy usando el encabezado Bearer con cada publicación y respondiendo a falla con un mensaje de autenticación / publicación para obtener un JWT de sesión que se incluirá en todos los encabezados: puedo ser estúpido, pero no veo cómo esto es menos seguro. Los detalles de las cookies están disponibles en la aplicación híbrida al igual que el token, aunque hay menos control sobre la persistencia ... Supongo que no entiendo por qué este es un enfoque tan malo. Seguro que necesita proporcionar credenciales para obtener el JWT, pero lo hace una vez, no en cada servicio.

Les pregunto esto: ¿cómo implemento una aplicación que utiliza 3 servicios diferentes (tal vez en una infraestructura de contenedores diferente, etc.) y los integro en la aplicación confiando en las cookies de sesión?

Depende de lo que hagan los 3 servicios. ¿Puedes elaborar?

Si configuro un servicio de autenticación y deseo desvincularlo de otro servicio, ¿cuál es el mejor enfoque para ejecutar un controlador de sesión de cookies de proxy compartido? ¿Es este un caso marginal?

Tendría que el servicio de autenticación emitiera un token JWT de un solo uso que indica una autenticación exitosa, que opcionalmente incluye 'información de perfil' para el usuario, dependiendo de su arquitectura. Luego, dependiendo de la aplicación:

1. Si es un sitio web normal: el servicio de autenticación redirige a una página de autenticación en el servidor de aplicaciones, por ejemplo. pasando el token JWT como parámetro de consulta. El servidor de aplicaciones valida el token y le da al usuario una cookie de sesión.
2. Si es un SPA: el servicio de autenticación devuelve el token generado en su respuesta (¿JSON?). La aplicación frontend realiza una solicitud HTTP al punto final de autenticación del servidor de aplicaciones, incluido el token como parámetro, y después de la validación por parte del servidor de aplicaciones, recibe una cookie de sesión a cambio.
3. Si es una aplicación independiente (de escritorio o móvil): como para un SPA, pero usando una biblioteca HTTP que admita cookies, en lugar de una aplicación de interfaz en un navegador.

En ambos casos, el token JWT solo será válido durante unos 5 minutos (para tener en cuenta la desviación del reloj) y se usará una vez, para intercambiarlo por una sesión en el servidor de aplicaciones. Si incluye información de perfil en el token, el servicio de autenticación permanece completamente desacoplado de la aplicación.

EDITAR: Caso de aplicación independiente agregado.

Supongamos que estamos en un escenario de desarrollo de aplicaciones móviles híbridas / SPA. También suponga que solo estamos usando JWT para la sesión, no OUATH con tokens de autenticación y portador, simplemente inicie sesión y reciba el token de portador.
Imaginemos que tenemos una aplicación en tiempo real con cada sesión realizando solicitudes a los 3 servicios cada 5-15 segundos. Muchos usuarios inician sesión para verificar el estado rápidamente o publicar datos GIS o algo por lo que el tiempo de uso promedio es de menos de 1 minuto, pero desean iniciar la aplicación, cerrarla, reiniciar 3 días después sin credenciales, etc. (agregando detalles que son en gran parte irrelevantes aquí, pero cosas que me alejarían de las cookies)

Como ejemplo, digamos que he creado un servicio AWS con un servicio de consulta de gráficos, un servicio de mapeo o GIS en un espacio de rack docker y una interfaz REST para postgres db para administrar los datos del perfil de usuario. Puedo usar el mismo JWT en solicitudes de encabezado para todos los servicios REST y validar contra un secreto común para tener una validación compartida del JWT emitida una vez.
Supongamos que tienen estado dentro de su propio contexto, pero solo vagamente en un contexto compartido.
Estas son especificaciones de problemas que coinciden con mi solución propuesta utilizando JWT como token de sesión como token de portador y, dado un entorno similar, le pregunto cómo abordaría el uso de cookies de sesión para que podamos comparar.

Digamos que todos requieren una confianza razonable en que el usuario es quien dice ser.
Mi solución sería generar un token JWT en respuesta a la publicación de credenciales que se usa en todos los servicios dentro del encabezado HTTP para autenticarse, y la validación se realiza con el secreto JWT compartido en todos los servicios.
El servicio de autenticación genera el token y lo devuelve al iniciar sesión. El token se incluye en las solicitudes de encabezado para todos los demás servicios en diferentes dominios. Si usamos cookies, necesitamos establecer nuevas cookies para cada dominio. ¿Por qué querría que los servicios que realizan nuevas solicitudes validen u obtengan una cookie por cada http recibido cuando puedo depender con confianza del JWT? Si tengo 5 servicios, ahora necesito administrar 5 cookies de sesión diferentes y asegurar la coordinación entre todos ellos. En muchos casos, este podría ser el enfoque correcto, pero en muchos me parece demasiado complejo para algo que es rápido y simple de implementar y no expone fallas de seguridad graves que puedo ver claramente.
¿Por qué limitar el plazo de JWT? Las cookies son tradicionalmente de corta duración porque asumen un contacto regular con el servidor; ¿qué sucede si no quiero que caduquen rápidamente pero estoy feliz de tener sesiones obsoletas de larga duración porque decido que la compensación de volver a autenticar es un riesgo mayor?

Si entiendo correctamente en su situación, tengo 9 solicitudes rebotando en cada período en lugar de 3. Tengo un servidor de autenticación activado para confirmar las sesiones establecidas. Tengo más código y más partes móviles. Tengo la ventaja de poder terminar las sesiones en cada período, pero ¿y si eso no es un requisito? ¿Qué pasa si no me importa recibir datos publicados durante otras 48 horas después de que el usuario haya sido cancelado y usando el servidor de autenticación para nuevas solicitudes todavía puedo filtrar lo que no necesito?

En este caso de uso, el sesgo de tiempo menor es irrelevante debido a que la granularidad de la sesión se establece de manera adecuada y, al igual que con las cookies de sesión, implementaría que el cliente actualice el JWT a través del servidor de autenticación en el período de tiempo de espera apropiado. En lo que respecta al 'perfil', sigamos con un uid compartido como el ID común (si lo entiendo correctamente) y las implementaciones del lado del servidor contienen un secreto compartido para firmar / validar el JWT.

En mi arquitectura propuesta, no necesito revocar los tokens con una granularidad más fina que la proporcionada por el tiempo de espera de JWT, entonces, ¿por qué debería usar cookies de sesión en su lugar?
En mi arquitectura propuesta, podría crear dependencias entre los estados de los servicios, pero podría diseñar esto en lugar de depender de que esté centralizado y necesite unir todo a la autenticación de forma predeterminada. La clave es la flexibilidad, y tiene el costo de darse cuenta de las dependencias, pero esto está en su cara desde el principio y no es una capa sobre algo que, aunque implementado en todas las plataformas, se maneja de manera diferente en todos los marcos. Puede que no sea trivial actualizar la caducidad de la cookie para una sesión con un nodo, php y manejo predeterminado de sesión de cookies exóticas sin realmente, por lo que se le puede animar a que publique una solicitud de servidor de autenticación directamente, por lo que no solo estamos disparando 3 veces más solicitudes pero hay 3 veces las solicitudes para el cliente.

Si me alineo con su arquitectura propuesta, entonces necesito lidiar con los tiempos de espera en múltiples cookies. Por ejemplo, si el cliente inicia sesión y recibe una cookie de sesión autorizada que caduca en 1 hora
y luego, 40 minutos más tarde, publican este valor de cookie de sesión en nuestro primer servicio, que luego consulta al servidor de autenticación antes de emitir una cookie de dominio local, ¿pirateamos la caducidad de la cookie de autenticación original interna o establecemos un tiempo de espera en la cookie de servicio a 20 minutos? y cuando esto expira, activa una actualización de la cookie de autenticación. A menos que me falte una solución obvia, esto puede convertirse fácilmente en una gran pila de espagueti que podría evitarse por completo usando un solo JWT con un solo ttl que podría actualizarse a través de cualquiera de los servicios (entendiendo cómo esto posiblemente extiende el token life) o requiriendo una actualización a través del servidor de autenticación.

Podría discutir enfoques para datos obsoletos, pero el alcance del problema en este caso de uso no se basa en invalidar credenciales obsoletas (desde la perspectiva del servidor de autenticación), por lo que esto no sería relevante.

Tengo entendido que estamos discutiendo su afirmación de que el uso de JWT como un enfoque de administración de sesiones autenticadas es inherentemente inferior e incorrecto en comparación con el uso de cookies de sesión como un enfoque de administración de sesiones autenticadas para servicios de dominio cruzado dentro de una aplicación móvil híbrida que se ejecutará en dispositivos de forma intermitente sin reabastecimiento de credenciales.

Estoy tratando de determinar si usted argumentaría que el enfoque propuesto es intrínsecamente menos seguro o menos "correcto" de alguna manera. A mi modo de ver, existen ventajas significativas en la simplicidad de esta arquitectura y ninguna ventaja que ofrece la solución más compleja y pesada requerida para administrar sesiones en todos los servicios que no se han tenido en cuenta y se han intercambiado por la arquitectura más simple. Si pudiera señalar cómo esta solución experimentaría problemas no experimentados al usar cookies para administrar sesiones, entonces realmente me ayudaría a comprenderlos explícitamente (es decir, cómo se compromete la seguridad)

Los servicios casi no importan, ¿no estás seguro de a qué te refieres?

Existe una diferencia entre los servicios con estado y sin estado.

Digamos [...]

Esto describe cómo resolvería el problema, no cuál es el problema. No es útil cuando me pide que explique cómo abordarlo con sesiones, porque ya supone que usted _no_ utilizará sesiones. En su lugar, describe el problema.

¿Cuándo puedo confiar con confianza en el JWT?

No puedes.

Si tengo 5 servicios, ahora necesito administrar 5 cookies de sesión diferentes y asegurar la coordinación entre todos ellos.

Improbable. Vea mi comentario sobre servicios con estado frente a servicios sin estado.

En muchos casos, este podría ser el enfoque correcto, pero en muchos me parece demasiado complejo para algo que es rápido y simple de implementar y no expone fallas de seguridad graves que puedo ver claramente.

La autenticación y la gestión de sesiones, especialmente en arquitecturas distribuidas, _es_ compleja. Hay una razón por la que los ingenieros han evitado las arquitecturas distribuidas siempre que ha sido posible en el pasado. "Simplemente use JWT" pasa por alto esto y pretende que es más fácil de lo que realmente es, al ignorar por completo la obsolescencia de los datos y la invalidación de sesiones.

Los agujeros de seguridad están ahí, y he hecho varios intentos para explicarlos; que no puedas verlos claramente, no es algo sobre lo que pueda hacer nada, si no haces preguntas específicas sobre las partes que no te quedan claras. .

¿Por qué limitar el plazo de JWT?

¿En el ejemplo que di? Porque están pensados ​​como tokens de intercambio de un solo uso, no como identificadores persistentes. No desea que sean identificadores persistentes, porque no puede revocarlos.

Las cookies son tradicionalmente de corta duración porque asumen un contacto regular con el servidor; ¿qué sucede si no quiero que caduquen rápidamente pero estoy feliz de tener sesiones obsoletas de larga duración porque decido que la compensación de volver a autenticar es un riesgo mayor?

No hay riesgo de actualizar una sesión.

ignorar el perfil o la desviación del reloj: detalles que no tienen un gran impacto en nuestra discusión en este caso hipotético, ya que se aplican los mismos problemas si se utilizan cookies para situaciones similares.

Son una parte tan importante de un sistema de autenticación sólido como todos los demás puntos mencionados. Ignorarlos no es una opción. Y nuevamente, esto _no_ se trata de "cookies", se trata de sesiones.

Para las sesiones, no, los mismos problemas _no_ se aplican; un almacenamiento de sesión centralizado / con estado significa que los datos no se vuelven obsoletos y la información del perfil se puede recuperar en cualquier momento, y la desviación del reloj es un problema para cualquier token de validez limitada que se intercambie entre diferentes sistemas.

Parece que podríamos resumir su objeción a JWT, ya que un enfoque de administración de sesiones podría depender de su adjunto a una definición de sesiones que requiere revocación por solicitud (y algunas otras características que tradicionalmente han sido parte para garantizar que un usuario esté autorizado para acceder) y el peligro asociado a actualizarlos (si son interceptados). El procesamiento distribuido es la nueva norma, los servicios múltiples son muy comunes, si vamos a adoptar el uso de este tipo de enfoque para la arquitectura de servicios múltiples, entonces debemos comprender completamente las consecuencias. Las bases de datos distribuidas existen desde hace mucho tiempo. Los almacenes de datos distribuidos como DNS existen desde el principio. A veces, la simplicidad de la arquitectura ofrece más beneficios que intentar exprimir el estándar dominante existente más allá de sus límites de diseño. Si somos conscientes de los problemas transaccionales de ACID en nuestras sesiones de solicitud de servicio, entonces no hay razón por la que no debamos adoptar un enfoque de gestión de sesiones JWT para autenticar los servicios para aprovechar al máximo las posibilidades sin estar limitados por lo que rápidamente se convierte en una infraestructura compleja si insistimos. en las restricciones estrictas y tratar de cookies de sesión de calzador como la solución que es superior.
@ joepie91 : cuando corresponda, puede usar la autenticación de sesión de cookies para la autenticación principal y solicitarla para actualizar el JWT. Nuevamente, el uso de JWT para el acceso al servicio de sesiones de dominio cruzado se puede usar como parte de la solución y la sesión de cookies también se puede usar si corresponde. El punto es que JWT como parte de la administración de sesiones, incluso para acceder a un subconjunto de servicios, no creo que sea un enfoque malvado que no tiene ningún papel.
Las cookies de sesión https también conllevan riesgos: es sorprendente cuántos sitios tienen la marca ssl sin configurar y pasan la cookie como texto sin formato cuando se comunican SSL. ¿Esto hace que las sesiones de cookies sean peligrosas?
El mayor riesgo que parece que puedo encontrar es que el codificador permite que el token se envíe al servidor incorrecto y que el token permita efectivamente que un tercero acceda a estos recursos de usuario secundarios. Esto debe estar marcado con letras rojas grandes en algún lugar y coloca una gran responsabilidad en el desarrollador para asegurarse de que esto no suceda. El desarrollador debe tomar las medidas adecuadas para asegurarse de que se han tomado las medidas de seguridad necesarias y un repositorio como este debe explicar algunos de estos enfoques e incluirlos en ejemplos. En mi opinión, este es un precio aceptable a pagar por la flexibilidad de la autenticación de servicio de tiempo limitado entre dominios para servicios no críticos.
Al diseñar una solución compleja, es probable que incluya cookies de sesión al final de la autenticación y puede extenderse para incluir tokens únicos, etc., cuando corresponda. El punto es que esto es posible y, si bien hay lugares en los que puede salir mal y exponer riesgos, brinda la oportunidad de crear aplicaciones más ricas y ágiles en muchos casos y, por esta razón, no creo que este repositorio deba almacenarse como se sugiere. por el registrador de problemas.
La inclinación a tratar de obtener lo mejor de ambos mundos mediante el uso de JWT como la cadena de sesión para mí parece presentar problemas, lo más sorprendente son los períodos de tiempo de espera / TTL posiblemente conflictivos. También impone las mismas restricciones de acceso al dominio que podríamos haber estado tratando de evitar en primer lugar, por lo que poner eso en el ejemplo básico puede llevar a la gente a preguntarse por qué usar JWT en primer lugar.

El uso de JS como dependencia es bastante menor: en el contexto de SPA móvil híbrido, es poco probable que necesite adaptarse a un cliente gratuito de JS. Sugerir que esto es un problema, al mismo tiempo que se afirma que redis proporciona una opción eficiente para el almacenamiento de sesiones, parece un poco contradictorio.
La expiración en el JWT no es inútil ya que proporciona un tiempo de espera de sesión que debe manejarse actualizando (exactamente de la misma manera en que se actualizan las sesiones de cookies) o requiriendo una nueva autenticación. Tener el JWT firmado garantiza que no haya sido manipulado y, por lo tanto, elimina el requisito absoluto de validación contra el almacenamiento persistente del lado del servidor, aunque esto se puede hacer si se desea y logra el mismo resultado que las sesiones de cookies sin una implementación tan obstinada y con la capacidad para utilizar dominios cruzados si es adecuado. En una aplicación móvil híbrida, el almacenamiento de cookies o JWT en el almacenamiento local nuevamente brinda más control. Las objeciones al uso del almacenamiento local sobre la seguridad de la implementación del navegador es una cuestión de confianza en el proveedor y aceptación de su manejo de estas credenciales.
La flexibilidad es útil para muchos desarrolladores de SPA híbridos móviles, pero requiere comprender cuáles son las limitaciones.
JWT se puede invalidar simplemente cambiando la clave de firma y, nuevamente, esto brinda flexibilidad: puede usar una clave de firma privada compartida común en todos los servicios o generar aleatoriamente por sesión de usuario y darse cuenta del tipo de beneficios de repudio de las cookies de sesión.
Casi todos los frameworks JS modernos son compatibles con JWT y sería difícil encontrar una plataforma importante que no lo hiciera; sin embargo, algunas probablemente no deberían hacerlo (el complemento JWT de Wordpress ... hmm ... no se mira, pero me pone nervioso).
El uso de JWT debe incluir antecedentes en OAUTH y las compensaciones y beneficios de usar sesiones de cookies. Para mí, existen ventajas laborales reales para los desarrolladores híbridos móviles promedio que utilizan múltiples servicios, pero hay trampas en las que es fácil caer. Es posible que necesitemos muchos ejemplos para ilustrar completamente.

Mi _ razonamiento original_ para usar un JWT como Token para la autorización es que verificar que un JWT está vinculado a la CPU (_ mi computadora portátil "vieja" puede verificar 180k JWT por segundo_) en contraste, si usáramos un token simple y tuviéramos que buscarlo en la memoria (o en una base de datos) la operación estaría ligada a E / S (_o peor, ligada a la red_) que sería _considerablemente más lenta_.
http://stackoverflow.com/questions/868568/what-do-the-terms-cpu-bound-and-io-bound-mean

Nuestro sistema de gestión de sesiones _primero_ verifica que el JWT sea válido verificando que se _firmó_ con nuestra clave - y rechaza un mensaje _ temprano_ si no lo fue - y _ luego_ verifica si la sesión aún no ha sido invalidada (por ejemplo, por el cierre de sesión del usuario) .

Sé que es posible que los JWT no hayan sido _diseñados_ para usarse como tokens en los encabezados de autorización, pero no creo que _ entienda completamente_ por qué es una "mala idea" dado que es _más rápido_ que otros sistemas de administración de sesiones ...

Nota: sigo de acuerdo en que el ángulo "sin cookies" no es la forma correcta de iniciar este archivo léame / tutorial. 👍