HISTORIA DE OAUTH: DE LAS CONTRASEÑAS A LOS ESTÁNDARES GLOBALES

Lo ves todos los días. Haces clic en "Iniciar sesión con Google" o "Iniciar sesión con GitHub". No escribes una contraseña. Entras al sitio al instante.

Esto funciona gracias a OAuth. Es el estándar global de seguridad. Pero no empezó así. Evolucionó para resolver problemas masivos.

El problema de las contraseñas

En los primeros días, creabas una contraseña nueva para cada sitio web. Esto causaba tres grandes problemas:

  • La gente usaba la misma contraseña en todas partes. Si un sitio se filtraba, todas las cuentas estaban en riesgo.
  • La gente olvidaba sus contraseñas. Pasaban más tiempo haciendo clic en "olvidé mi contraseña" que usando la web.
  • Los sitios web veían tu contraseña en texto plano. Si un sitio era hackeado, tu contraseña quedaba expuesta.

La evolución de la seguridad

  1. Basic Auth: Enviabas tu nombre de usuario y contraseña con cada solicitud. Si no usabas HTTPS, los hackers podían verlo todo.

  2. Session Cookies: Iniciabas sesión una vez y obtenías un ID de sesión. Era mejor, pero las cookies pueden ser robadas mediante ataques como XSS o CSRF. Además, un sitio no podía usar tu inicio de sesión para comunicarse con otro sitio.

  3. API Keys: Le dabas a un sitio web una clave especial. Esto era mejor porque no enviabas tu contraseña. Sin embargo, las API keys suelen tener demasiado poder. Si le das una API key a una aplicación, esa aplicación podría tener el poder de leer tus correos, enviar mensajes y eliminar tu cuenta. Es como darle la llave de tu coche al valet de un hotel, pero que esa llave también abra tu casa.

La solución de OAuth: La llave del valet

OAuth cambió las reglas del juego. En lugar de dar tu contraseña, entregas un "token". Piénsalo como una llave de valet. Una llave de valet permite que un conductor estacione tu coche, pero no le permite abrir el maletero ni acceder a tu casa.

Cómo funciona OAuth en la práctica:

  • Quieres usar Canva y extraer fotos de Google.
  • Canva le pide permiso a Google.
  • Google te pregunta: "¿Puede Canva ver tus fotos?"
  • Tú dices: "Sí, pero solo ver. No permitas que borren nada".
  • Google le da a Canva un token específico.

Canva nunca ve tu contraseña de Google. Incluso si un hacker roba ese token, solo podrá ver las fotos por un corto tiempo. No puede cambiar tu contraseña ni mover tu dinero.

Seguridad moderna: PKCE

Las aplicaciones móviles y web tienen una debilidad. No pueden ocultar secretos fácilmente. Para solucionar esto, usamos PKCE (Proof Key for Code Exchange).

Funciona como un sistema de reservas:

  • La aplicación crea un código secreto (el verificador).
  • La aplicación envía una versión hasheada de ese código (el desafío) a Google.
  • Cuando la aplicación solicita el token, envía el código secreto original.
  • Google comprueba si el código coincide con el desafío.

Si coinciden, Google sabe que es la misma aplicación. Si no coinciden, Google bloquea la solicitud. Esto evita que los hackers roben tu código de autorización.

La hoja de ruta de OAuth

  • 2007 (OAuth 1.0): Muy complejo y utilizaba matemáticas pesadas.
  • 2012 (OAuth 2.0): Más rápido y fácil. Utilizaba tokens y requería HTTPS.
  • 2016 (OAuth 2.0 + PKCE): Añadió seguridad para aplicaciones móviles y web modernas.
  • 2023 (OAuth 2.1): El nuevo estándar de oro. Elimina los métodos antiguos e inseguros.

La lección fundamental: Nunca entregues tu contraseña a otra aplicación. Entrégales un ticket limitado que expire. Tú mantienes el control.

Source: https://dev.to/gophernment/oauth-elaaaebbprawatisaastr-cchaakrhasphaan-suumaatrthaanolk-16b4