¿Cuáles son las preocupaciones con JWT?

Clase 28 de 39 • Curso de Autenticación con OAuth

Resumen

Cuando guardamos nuestros JWT en el localStorage del navegador, somos vulnerables a ataques de Cross Site Scripting (XSS).

En realidad, debemos tratar estos tokens como si fueran datos de la tarjeta de crédito de nuestros usuarios, nunca deberíamos almacenarlos en ninguna parte, más bien, podemos almacenarlos en memoria (mejor aún si tenemos la posibilidad de utilizar al backend y podemos implementar el flujo de Authorization Code Grant para conservar los datos en la memoria del servidor).

También existen varias alternativas basadas en JWT como JWS, JWE y JOSE, sin embargo, ninguna de ellas es la respuesta definitiva a todos los problemas de seguridad en nuestras aplicaciones, nuestro trabajo NO es asegurarnos de que nuestra tecnología sea la más poderosa, más bien, debemos trabajar con el mejor conjunto de buenas practicas con buenas tecnologías.

El desafio de esta clase es describir las diferencias entre OAuth 1.0 y OAuth 2.0 en la sección de comentarios.

Héctor Tello

student•

Encontré qué tiene OAuth 2.0 que OAuth 1.0 no:

Ya no requiere de cliente de las aplicaciones de la criptografía.
Sus firmas son mucho menos complicadas.
Sus token de acceso son de "corta duración".

Anyx Tronandix

student•

Los protocolos OAuth1 y OAuth2 son muy diferentes, si bien los dos son usados para el manejo de la autorización. OAuth 2 fue completamente reescrito pudiendo decir así que OAuth2 es un protocolo completamente nuevo.

Diferencias sustanciales:

OAuth2 fue creado en base a la necesidad de usar protocolos de authorization en aplicaciones que no dependen de un browser ya que OAuth1 dependía enteramente de uso de un browser incluso si las aplicaciones eran de escritorio, para usar este protocolo tenías que abrir un browser e iniciar el proceso des authorization de aplicación.
OAuth1 maneja sus propios mecanismos de seguridad sobre SSL y TCL, e implementa sus propios mecanismos para evitar vulnerabilidades, mientras OAuth2 confía toda la responsabilidad en el protocolo https.
Las definiciones de los actores son diferentes, por ejemplo en OAuth2 tenemos: Cliente, Servidor de Autorizción, Servidor de reursos y Dueño de los recursos, mientras en OAuth1 Tenemos Cutomer que sería el equivalente al Cliente, User que sería el equivalente a resource owner y Service provider que sería como el resource owner. Una diferencia también es que OAuth1 no separa los roles de un servidor de recursos y un servidore de authorization.
OAuth1 maneja protocolos de encriptación para firmar llaves lo que puede resultar muy tedioso aveces.
OAuth2 cuenta con más flujos y es más flexible para ser utilizado por diferentes tipos de aplicaciones.
Ya que OAuth1 maneja sus propios protolos de seguridad suele ser más seguro que OAuth2 aunque se tenga la impresión de lo contrario.
OAuth1 maneja sus propios mecanismos de seguridad sobre SSL y TCL, e implemta sus propios mecanismos para evitar bulnaberidades, mientras OAth2 confia toda la responsabilidad en el protocolo https

MARIO FERNANDO RAMIREZ AGUIAR

student•

Auth 2.0 Es un protocolo que define las reglas para acceder a otro servidor Auth 1.0 Permite la autorización a las aplicaciones pero de un mono mas estándar

Juan Diego Silva Garcia

student•

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies Aqui pueden encontrar información de los flags para proteger las cookies.

Javier Ramos

student•

Me volvió el alma al cuerpo al explicar que los Bancos estan protegidos contra ese tipo de ataque que es solo un ejemplo

Alejandro Cepeda

student•

Si guardo en memoria el token, de igual forma con las developer tools de chrome puede ver ese header que se esta enviando

Cesar Eduardo Valle Pino

student•

PASETO: Platform-Agnostic Security Tokens

Jesus Ruvalcaba Miranda

student•

en el caso que comenta sobre la utilización de redux para almacenar los tokens en memoria, como generarias persistencia sin ponerlo en el localstorage

Guillermo Rodas

teacher•

Hay varias formas/estrategias de hacer esto. 1) Lo que puedes hacer es tener una acción que compruebe que el usuario este logueado antes de llamar el resto de acciones. Esto con el fin de que si alguien entra a alguna vista generando un request en el servidor tu puedas primero hacer el re-login. Para eso necesitarias posiblemente un mecanismo de refresh tokens o silent auth.

La otra opción es usar cookies de manera segura, tendrias que hacer un puente entre tu SPA y un servidor exclusivo para esto, si estas haciendo SSR podrias usar este mismo servidor.

Informacón adicional: https://auth0.com/blog/oauth2-implicit-grant-and-spa/

Diego Joel Requejo Torero

student•

Diferencias entre OAuth 1.0 y OAuth 2.0:

Flujo de autorización: OAuth 1.0 utiliza está basado en tokens, en el que el servidor de recursos emite un token de solicitud de acceso al cliente y un token de acceso al servidor de autorización después de la autorización del usuario. OAuth 2.0 está basado en el servidor de autorización, en el que el cliente solicita el acceso a un recurso protegido directamente al servidor de autorización y recibe un token de acceso en respuesta.
Reutilización de tokens: En OAuth 1.0, un token de acceso solo se puede utilizar para acceder a un recurso protegido específico, mientras que en OAuth 2.0, un token de acceso se puede reutilizar para acceder a múltiples recursos protegidos.
Manejo de errores: En OAuth 1.0, los errores de autorización se manejan mediante códigos de estado HTTP y mensajes de error. En OAuth 2.0, se utiliza un esquema de manejo de errores más estructurado con códigos de error específicos.
Extensiones: OAuth 2.0 ofrece más extensiones y opciones de personalización que OAuth 1.0, lo que permite a los desarrolladores adaptar mejor el protocolo a sus necesidades específicas.

ALVARO RODRIGUEZ TAMEZ

student•

Excelente clase.

Jesus Olivares

student•

Tengo un api administrativo (donde gestiono el contenido de la pagina, usuarios, ect) y uno publico (donde los usuarios hacen sus publicaciones y ven contenido de otros usuarios), Ambas son SPA... Como hago para evitar que una persona agarre el token del panel administrativo y lo use desde la otra aplicacion que es solo para realizar publicaciones y ver contenido (y por ejemplo modifiquen el nombre de una categoría desde la aplicación que no es)..?

Fernando Sanabria Marroquín

student•

Uff no pensé que la historia fuera tan interesante, les comparto: https://www.oauth.com/oauth2-servers/differences-between-oauth-1-2/

Juan Pablo Cano Buitrago

student•

Tengo un backend en Django REST Framework y un front en Angular 8, Cual de todos los flujos de OAuth debería iplementar?

Guillermo Rodas

teacher•

Puedes implementar Implicit Grant, o implementar Authorization Code Grant, pero necesitarias un servidor proxy o de SSR para usar este ultimo.

Juan Pablo Cano Buitrago

student•

Implicit Grant lo implemento en Angular o en Django

Guido Ortega

student•

no me queda claro como enviando el atributo state en la petición se puede evitar CSFR, es decir que hace el backend con esa cadena que enviamos y como el tiene conocimiento de que la cadena fue creada por nosotros? de antemano gracias!

Guillermo Rodas

teacher•

La petición de authenticacion solo puede ser generada nuestra aplicacion, ya que desde el cliente es el usuario quien genuinamente acepta otorgar los permisos y en esa misma peticion enviamos nuestro state. De igual manera se aplica el concepto en Authorization Code Grant, cuando es el backend quien genera el state.

Lo que queremos hacer es evitar que alguien nos envie una peticion a nuestra URL callback de nuestro cliente de manera falsa, ya que solo nosotros sabemos cual state generamos.

Aquí hay dos explicaciones basicas de como funciona el concepto:
https://auth0.com/docs/protocols/oauth2/oauth-state#how-to-use-the-parameter-against-csrf-attacks
https://librosweb.es/libro/django_1_0/capitulo_14/proteccion_contra_csrf.html#un_ejemplo_mas_complejo_de_csrf

Pedro José Miranda Castro

student•

La comunidad IETF tiene un documento (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2) muy interesante donde recomiendan dejar de usar el flujo Implicit Grant básicamente porque está naturalmente expuesto a fuga y reproducción de los tokens. La ventaja es que recomiendan usar Authorization Code Grant, lo que en teoría le hace más fácil la vida al desarrollador, sin embargo para las apps nativas el estándar sigue siendo Auth Grant PKCE.