Soy el autor de ese artículo, así como la charla sobre tecnología más popular que ofrezco acerca de por qué los JWTs apestan y son estúpidos (todos los cuales @ joepie91 ha escrito con elocuencia de manera mucho mejor de lo que podría: enlace ).
Teniendo en cuenta los requisitos de su aplicación (aplicación móvil + aplicación única de front-end JS que ambos hablan con una API de back-end), le sugiero que use el flujo de Código de Autorización de OpenID Connect (con PKCE para su aplicación móvil).
Para su aplicación móvil, específicamente, recomiendo usar la fabulosa biblioteca AppAuth: enlace (tiene bibliotecas geniales para iOS + Android ).
Ahora, quizás se esté preguntando por qué recomendaría usar OpenID Connect (y, por lo tanto, JWTs) para algo cuando yo tan públicamente reúno a las personas en contra de usar JWTs: le diré, para la mayoría de las cosas no importa. .
Aquí está la cosa: sí, los JWT son bastante difíciles de usar cuando se crean aplicaciones seguras. Son complicados, la mayoría de las bibliotecas actualmente no están completas, y es casi seguro que el uso de funciones más avanzadas como el cifrado JWT le causará grandes dolores de cabeza y problemas de compatibilidad entre sus servicios.
Además, la razón principal por la que los JWT se han hecho populares para la autenticación es que se utilizan con frecuencia para autenticar CACHE y los datos de autorización, toda esta práctica es un gran NO NO en el mundo de la seguridad.
El almacenamiento en caché de datos confidenciales (como datos de autenticación y autorización) es lo peor que puede hacer por seguridad: está confiando en información obsoleta. TODOS los sistemas de autenticación actuales construidos sobre JWTs sufren esta ingenuidad.
Una vez que haya pasado por el agujero de los conejos al tratar de "acelerar" su sitio / API mediante el uso de JWT, ya cometió un pecado de seguridad y ahora está en riesgo.
Además, una vez que las personas comienzan a usar JWT y se dan cuenta de que están en riesgo, intentan volver a centralizar todo (como ha sugerido otro comentarista) y comienzan a usar las listas de revocación para poder revocar tokens cuando suceden cosas malas. Esto da como resultado las mismas penalizaciones de velocidad que la administración de sesión tradicional, pero con mayores penalizaciones de velocidad debido a que los JWT son más "pesados" que las cookies de sesión, y más frágiles.
Lo siento por la perorata, pero aquí está mi consejo:
- Si desea seguridad real , debe usar sesiones del lado del servidor. En su caso, esto implicaría el uso de cookies de sesión de soporte desde su backend API, de modo que cuando su aplicación reaccione se autentique en su API, la API establece una cookie segura que la aplicación reacciona utiliza automáticamente cada vez que responde al servicio API para autenticarse. También deberías usar una API basada en cookies desde tu aplicación móvil (no estoy familiarizado con la creación de aplicaciones móviles nativas, por lo que no puedo comentar sobre este componente).
- Si desea simplicidad y la misma cantidad de seguridad que en casi todas las demás aplicaciones web principales, utilice OIDC y salga con las soluciones de código abierto listas para usar. Esta es la forma más sencilla de hacerlo actualmente y, si bien no es perfecta, si resuelve su problema, probablemente no sea un gran problema.
Si está creando algo sensible, intente usar cookies de sesión del lado del servidor cuando sea posible. ¿De otra manera? No se preocupe por los detalles y siga la corriente.