¿Cuáles son las preocupaciones con JWT?

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”.

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

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

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

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

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

PASETO: Platform-Agnostic Security Tokens

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

Diferencias entre OAuth 1.0 y OAuth 2.0:

1. 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.
2. 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.
3. 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.
4. 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.

Excelente clase.

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)…?

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

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

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!