{"id":1193,"date":"2022-11-16T04:04:56","date_gmt":"2022-11-16T04:04:56","guid":{"rendered":"https:\/\/blog.thepragmatic.xyz\/?p=1193"},"modified":"2023-03-12T22:34:31","modified_gmt":"2023-03-12T22:34:31","slug":"json-web-tokens","status":"publish","type":"post","link":"https:\/\/blog.thepragmatic.xyz\/?p=1193","title":{"rendered":"JSON Web Token based authentication"},"content":{"rendered":"\n

Intro Diego<\/h2>\n\n\n\n

Cookies<\/strong> (Viejas) de lado cliente se puede ver la info en el header (forma insegura guardar informacion, cambiar informacion del lado del servidor) (Preferencias, anuncios) STATEFUL (seguimiento del estado de la informaci\u00f3n) Almacenar preferencias del idioma, configuraciones (custom para no iniciar desde 0)<\/p>\n\n\n\n

tradicional <\/strong>(Basado en sessi\u00f3n) guardar informacion a trav\u00e9s del servidor, pero utilizando cookies. SESIONES: toda la informacion se guarda del lado del servidor, mientras se tiene la sesi\u00f3n abierta.<\/p>\n\n\n\n

traer la informacion del usuario a trav\u00e9s de una cookie, ya no se guarda toda la informaci\u00f3n, sino un ID o un registro que le permite al servidor identificar a que usuario pertenece ese ID (PHPSESSID=3c7f0j34). Las sesiones conviven tanto del lado del servidor como del cliente, en el cliente solo se tiene un ID que se guarday cada que se haga una request HTTP, el navegador va a tomar esa cookie si existe y la envia de vuelta al servidor. En el servidor se valida el id o el registro que tiene almacenado y con eso se identifica la informacion asociada a ese id. M\u00e9todo un poco mas seguro, no se guarda toda la info de lado del cliente (exposicion data sensible), ahora la informacion esta del lado del servidor. No es totalmente segura pero garantiza un nivel mayor de proteccion sw la informacion.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Historia<\/h2>\n\n\n\n

El proceso de autenticaci\u00f3n ha evolucionado bastante los \u00faltimos a\u00f1os debido a la revoluci\u00f3n m\u00f3vil, la arquitectura de aplicaciones basadas en microservicios, cloud computing e IoT. Las conexiones ya no se establecen con servicios internos de las compa\u00f1ias exclusivamente, todos o la mayor\u00eda de nuestros dispositivos se conectan a internet o redes p\u00fablicas que dejan fuera los controles de seguridad que se dispon\u00edan en las redes privadas.<\/strong> Surgieron algunos retos, la gran cantidad de clientes, dificultad para escalar y finalmente el manejo de sesi\u00f3n; Para solucionar esta necesidad aparecieron 3 tecnolog\u00edas: JSON Web Tokens, OAuth 2.0, OpenID Connect. Qu\u00e9 actualmente son consideradas como el stack de seguridad para aplicaciones modernas<\/strong><\/em>. En este art\u00edculo se tratar\u00e1 la autenticaci\u00f3n basada en JSON Web Tokens<\/strong>, cabe aclarar que el concepto de token se introduj\u00f3 en las aplicaciones web por la autenticaci\u00f3n y autorizaci\u00f3n moderna y su uso se extiende gracias al protocolo Oauth (actualmente OAuth 2.0), centrados en la autorizaci\u00f3n y no en la autenticaci\u00f3n como se tienden a confundir. PULIR<\/mark><\/p>\n\n\n\n

\u00abLa principal diferencia entre OAuth y OpenID Connect es que OAuth se centra en la autorizaci\u00f3n, mientras que OpenID Connect se centra en la autenticaci\u00f3n. OAuth se utiliza para permitir que las aplicaciones de terceros accedan a los recursos protegidos de un usuario en un servicio en l\u00ednea, mientras que OpenID Connect se utiliza para autenticar a los usuarios en aplicaciones web y m\u00f3viles.\u00bb

OAuth se centra en la autorizaci\u00f3n, y no en la autenticaci\u00f3n, es decir, permite que una aplicaci\u00f3n acceda a los recursos de un usuario sin revelar su contrase\u00f1a o credenciales de autenticaci\u00f3n al tercero.<\/em><\/p>

OIDC utiliza los mecanismos de autorizaci\u00f3n de OAuth 2.0 y agrega una capa de autenticaci\u00f3n en la parte superior. OIDC permite a los usuarios autenticarse con una identidad digital (por ejemplo, una cuenta de Google) y recibir un token de acceso para acceder a los recursos protegidos en una aplicaci\u00f3n de terceros.<\/em><\/p>random<\/cite><\/blockquote>\n\n\n\n

Ahora es pertinente aclarar los tipos de autenticaci\u00f3n con tokens: <\/p>\n\n\n\n

Autenticaci\u00f3n tradicional o autenticaci\u00f3n en servidor<\/strong><\/td>Autenticaci\u00f3n sin estado basada en tokens<\/strong><\/td><\/tr>
Fue el modo de autenticaci\u00f3n m\u00e1s habitual. Al usuario autenticarse el servidor le devuelve al cliente un token que es almacenado en una cookie. El servidor guarda la informaci\u00f3n de la sesi\u00f3n en memoria o en base de datos. Al solicitar un recurso con ese token, el servidor realiza la b\u00fasqueda para identificar quien intenta acceder y si es v\u00e1lida, ejecuta la solicitud. Puede presentar sobrecargas (cantidad de usuarios) y problemas de escalabilidad (replicar la sesi\u00f3n en varias instancias). Vulnerabilidades asociadas a la arquitectura (CORS, CSRF).
Intercambio de recursos de origen cruzado
falsificaci\u00f3n de petici\u00f3n en sitios cruzados)<\/td>		Stateless significa que el servidor no almacena ninguna informaci\u00f3n, ni tampoco la sesi\u00f3n. Al usuario autenticarse, recibe un token (access token<\/strong>) en la respuesta. Desde ah\u00ed todas las peticiones hacia la API llevar\u00e1n este token (HTTP header), as\u00ed el servidor podr\u00e1 identificar al usuario que hace la petici\u00f3n sin necesidad de hacer consultas. Se proporciona escalabilidad, las peticiones podr\u00edan ser atendidas por cualquier instancia del servidor sin requerir sincronizaci\u00f3n ya que el cliente almacena su informaci\u00f3n de autenticaci\u00f3n y no el servidor. Diferentes plataformas podr\u00e1n usar la misma API.
Al no existir sesiones (RESTFul) se evitan vulnerabilidades CSRF. La expiraci\u00f3n del token provee una mayor seguridad.
<\/td><\/tr><\/tbody><\/table>
Comparativo autenticaci\u00f3n tradicional vs Basada en tokens.<\/figcaption><\/figure>\n\n\n\n

\u00bfQu\u00e9 son JSON Web Tokens?<\/h2>\n\n\n\n

Seg\u00fan la RFC 7519:<\/p>\n\n\n\n

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and\/or encrypted.<\/mark><\/em><\/p>\n\n\n\n

B\u00e1sicamente es un est\u00e1ndar abierto de intercambio de datos entre 2 partes (sistemas) basado en JSON, que permite crear tokens de acceso, actualmente est\u00e1 bien aceptado pero hay mas alternativas. Se puede encontrar en est\u00e1ndares populares, como OpenID Connect u OAuth 2.0. Es ampliamente utilizado en empresas de diversas escalas, existen variedad de bibliotecas compatibles con JWT, cuenta con gran soporte. Propone que no haya un estado en el servidor de autenticaci\u00f3n, por ende coincide bastante con las API RESTFul. Se utilizan tokens firmados con las credenciales de autenticaci\u00f3n de los usuarios en vez de guardar estos estados con cookies en los servidores, como lo hace la autenticaci\u00f3n basada en sesi\u00f3n.<\/p>\n\n\n\n

As\u00ed se ve un JSON Web Token:<\/p>\n\n\n\n

\"\"\/
Imagen n: Estructura de un JSON Web Token [Redise\u00f1ar imagen]<\/em><\/figcaption><\/figure>\n\n\n\n

Visto de otra forma JWT es una secuencia de caracteres en formato JSON codificados en la estructura JWS (JSON Web Signature) o JWE (JSON Web Encryption). Esencialmente sirven para representar unos claims (permisos, requerimientos, privilegios) entre 2 partes. A su vez suele ser un simple par de \u201cclave\u201d: \u201cvalor\u201d.<\/mark> CORROBORAR. PODRIA CABER UN PARA QUE SIRVEN?<\/p>\n\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

\u00bfC\u00f3mo funciona un sistema de autenticaci\u00f3n basado en JWT?<\/h2>\n\n\n\n

Simplemente una de las partes genera y entrega un token con la identificaci\u00f3n y los permisos de cada usuario. Este token es almacenado por la otra parte es decir el cliente, y enviado cada que requiera utilizar o consumir cierto recurso. As\u00ed que siempre que las aplicaciones necesitan verificar los permisos de los usuarios, simplemente deben validar los tokens. Se conf\u00eda en que el JSON Web Token es el mecanismo que le concede esos permisos o autorizaciones. Gracias a este tipo de autenticaci\u00f3n se descarta el uso de un servicio de backend para almacenar las sesiones de autenticaci\u00f3n de los usuarios, solo con guardar y validar los tokens se pueden controlar los permisos para cada usuario.<\/p>\n\n\n\n

En esencia son 3 cadenas de texto, separadas por un punto, la primera cadena corresponde al header, hay que aclarar que esto no est\u00e1 cifrado est\u00e1 codificado, quiere decir que se puede decodificar es reversible. <\/p>\n\n\n\n

<\/p>\n\n\n\n

Dilema del manejo de sesi\u00f3n \u00abNo uses JWT para gestionar sesiones\u00bb (Detractores)<\/h2>\n\n\n\n

Muchas personas intentan comparar \u201ccookies vs JWT\u201d. Esta comparaci\u00f3n no tiene sentido, y es comparar manzanas con naranjas -las cookies son un mecanismo de almacenamiento, mientras que las JWT tokens son tokens firmadas criptogr\u00e1ficamente. No son opuestos<\/strong> – sino que pueden ser usadas ya sea de manera conjunta o independiente. La comparaci\u00f3n correcta es \u201csesiones vs JWT<\/strong>\u201d y \u201ccookies vs Local Storage\u201d. Los JWT no son adecuados como un mecanismo de sesiones.<\/p>\n\n\n\n

Los casos de uso donde las JWT son particularmente efectivas son t\u00edpicamente los casos de uso donde son usadas como un token de autorizaci\u00f3n de \u00fanico uso. Pero como todo en la vida y en la ingenieria \u00abdepende\u00bb. Hay una fuerte discusi\u00f3n en torno a este dilema, no es el objetivo de esta exposici\u00f3n, pero les dejo la inquietud, por si alguien esta interesado en ahondar.<\/p>\n\n\n\n

Ventajas y Desventajas<\/h2>\n\n\n\n
Ventajas<\/td>Desventajas<\/td><\/tr>
F\u00e1cil implementaci\u00f3n y posibilidad de customizaci\u00f3n.<\/td>Alto riesgo en caso de que el secret sea comprometido. De ser as\u00ed la \u00fanica soluci\u00f3n es generar uno nuevo, lo que implica nuevo login para todos.<\/td><\/tr>
Puede ser firmado mediante una clave p\u00fablica y privada, o utilizando un secret (HMAC).<\/td>F\u00e1cil de implementar, dif\u00edcil de comprender debido a los algoritmos que se utilizan para firmar el token.<\/td><\/tr>
Portable, un mismo token puede utilizarse en m\u00faltiples backends.<\/td>Data overhead, a mayor informaci\u00f3n que agreguemos en el body, mayor el tama\u00f1o del request.<\/td><\/tr>
No hay manejo de sesi\u00f3n ni cookies (stateless). Utilizado por Single Page Applications (IoT)<\/td>No hay forma de bloquear un token en tiempo real,. S\u00ed se puede bloquear un refresh token<\/td><\/tr>
Buena performance, luego de la autenticaci\u00f3n no necesita de recursos externos para validar el token.<\/td><\/td><\/tr><\/tbody><\/table>
Tabla: Ventajas y Desventajas<\/figcaption><\/figure>\n\n\n\n

Tipos de token<\/h2>\n\n\n\n

Existen muchos tipos de token, lo mas comunes son el access token y el refresh token.<\/p>\n\n\n\n