Por Fin Entendí OAuth 2.0: La Guía Definitiva para Desarrolladores

Por Fin Entendí OAuth 2.0: La Guía Definitiva para Desarrolladores

Seamos honestos: OAuth 2.0 puede parecer un misterio envuelto en un enigma. La idea general es simple: «permitir que una aplicación use los datos de otra de forma segura». Pero cuando miras los detalles, de repente te encuentras ahogado en un mar de parámetros con nombres extraños, redirecciones y tokens.

Estuve en ese barco durante mucho tiempo, hasta que comencé a construir mi propia biblioteca de autenticación. Fue entonces cuando tuve que profundizar en el meollo de la cuestión, leyendo cientos de páginas de especificaciones de OAuth (sí, fue tan divertido como suena 😅). ¿Pero sabes qué? Después de todo eso, me di cuenta de que OAuth es realmente súper lógico. Cada parámetro es solo para prevenir uno o más tipos de ataques. 🛡️

En este artículo, comenzaré con el flujo de «autenticación» más simple que pueda imaginar: compartir sus contraseñas. A partir de ahí, abordaremos cada vulnerabilidad una por una, asegurándola paso a paso hasta que lleguemos al flujo completo y seguro de OAuth que conoces y amas (o tal vez simplemente toleras).

Stack Auth: Alternativa de código abierto a Auth0/Clerk

Antes de sumergirnos, quiero presentar rápidamente Stack Auth, la biblioteca de autenticación de código abierto que estamos construyendo. ¡Está diseñado para ser muy fácil de configurar y ofrece un hermoso conjunto de componentes de interfaz de usuario desde el primer momento! Ya sea que esté creando un producto SaaS o su próximo proyecto paralelo, Stack Auth simplifica la autenticación sin comprometer la flexibilidad.

El mundo sin OAuth

Big Head quiere ahorrar espacio de almacenamiento en su unidad Hooli Cloud. Encuentra Pied Piper, una aplicación que promete comprimir sus archivos. Pero para que Pied Piper haga su magia, necesita acceso a su unidad Hooli.

La forma más sencilla de obtener ese acceso para Pied Piper es pedirle a Big Head su nombre de usuario y contraseña de Hooli. Con ellos, Pied Piper puede iniciar sesión en Hooli en su nombre y acceder a sus archivos.

Así es como sería:

La pantalla que Big Head ve en su navegador podría verse así:

Ataque #1: Las credenciales de Big Head quedan expuestas

Al entregar su nombre de usuario y contraseña, Big Head le da a Pied Piper acceso completo a toda su cuenta de Hooli. ¡Esto incluye Hooli Mail, Hooli Chat e incluso la capacidad de cambiar su contraseña! Además, si alguien alguna vez piratea Pied Piper, podrá ver la contraseña de Big Head en texto sin formato.

Entonces, se les ocurre un nuevo plan: generar un token de acceso. Esta es una clave que permite a Pied Piper acceder a los datos de Big Head en Hooli con permisos limitados.

Y así es como se vería Big Head:

Si bien este enfoque es seguro, no es particularmente fácil de usar. Big Head no quiere generar un token de acceso manualmente cada vez que comprime un archivo o inicia sesión en un servicio. Quiere que el flautista de Hamelín lo haga por él.

Automatización

En lugar de que Big Head genere tokens de acceso manualmente y los copie en Pied Piper, Pied Piper puede pedirle a Hooli que genere tokens de acceso en su nombre.

¡Esto sería increíble si no hubiera malos actores en este mundo! Big Head solo necesita hacer clic en un botón y todo se hace automáticamente. Pero, hay un problema obvio aquí.

Ataque #2: Cualquiera puede afirmar ser cualquier otra persona

¡No hay absolutamente ninguna seguridad en este enfoque! Pied Piper puede fingir que actúa en nombre de cualquiera, y Hooli felizmente generará un token de acceso.

Entonces, para asegurarse de que la solicitud sea realmente de Big Head, Hooli necesita pedirle confirmación.

En el amplio mundo de la web, el paso 3 generalmente se realiza redirigiendo a Big Head a una página en un dominio. Entonces, su navegador mostraría esto:hooli.com

Hooli ahora puede verificar que la persona sentada frente al navegador es Big Head. En el paso 3, Hooli puede diseñar libremente el proceso de confirmación. Hooli podría pedirle a Big Head que confirme su inicio de sesión con correo electrónico / contraseña, haga 2FA y / o solicite consentimiento.

Ponerle un nombre: flujo implícito

Las primeras implementaciones de OAuth se veían exactamente así; lo llamamos el flujo implícito. Sin embargo, ni siquiera estamos a la mitad de esta publicación, por lo que tal vez pueda adivinar que no debería usar esto en sus aplicaciones de producción.

Pero, comencemos a dar nombres a las cosas, de acuerdo con lo que OAuth las llama:

Los parámetros de consulta de la URL son:

• client_id=piedpiper: Esto le dice a Hooli qué aplicación está solicitando acceso (en este caso, Pied Piper).
• redirect_uri=https://piedpiper.com/callback: Aquí es donde Hooli debería enviar a Big Head de regreso después de aprobar la conexión.
• scope=drive: Los permisos que necesita Pied Piper.
• response_type=token: Le dice a Hooli que estamos usando el flujo implícito.

¡Hasta ahora, bien!

Ataque #3: Manipulación de URI de redireccionamiento

Endframe, un competidor malicioso de Pied Piper, quiere robar los datos de la unidad Hooli de Big Head.

1. Endframe envía a Big Head un correo electrónico con el asunto: «Conecta tu cuenta de Hooli con Pied Piper».
   • Incluyen un enlace a , con el mismo y como una solicitud real de Pied Piper.https://hooli.com/authorize?...client_idscope
   • Pero cambian el parámetro a .redirect_urihttps://endframe.com
2. Big Head verifica el dominio y ve que es , por lo que hace clic en el enlace.hooli.com
3. Aparece la pantalla de consentimiento de Hooli. Big Head confirma que es el ID de cliente de Pied Piper, por lo que inicia sesión y confirma el acceso.
4. Sin embargo, después de que Big Head hace clic en «Permitir», Hooli lo redirige a en lugar de , enviando el token de acceso a Endframe.https://endframe.comhttps://piedpiper.com/callback
5. ¡Ahora, Endframe tiene acceso a la unidad Hooli de Big Head!

El problema es que Hooli no verificó que y coincidan.client_idredirect_uri

La solución es requerir que Pied Piper registre primero todos los URI de redireccionamiento posibles. Entonces, Hooli debería negarse a redirigir a cualquier otro dominio.

Ataque #4: Falsificación de solicitudes entre sitios (CSRF)

Sin embargo, hay algunos ataques más avanzados. Endframe aún puede engañar a Big Head para que inicie sesión con una cuenta maliciosa de Hooli:

1. Endframe registra una cuenta con Pied Piper.
2. Inician sesión en Pied Piper y generan un token de acceso para su propia unidad Hooli.access_token_456
3. Le envían a Big Head un correo electrónico con el título «Echa un vistazo a nuestro álbum de fotos de Bachmanity» y un enlace.https://piedpiper.com/callback?access_token=access_token_456
4. Big Head comprueba el dominio, ve que es y hace clic en él.piedpiper.com
5. El sitio web de Pied Piper abre la devolución de llamada e inicia sesión en Big Head en la unidad Hooli de Endframe, por lo que cualquier archivo que cargue irá a la unidad Hooli de Endframe.

¿Cómo podemos prevenir esto? Necesitamos asegurarnos de que solo finalizamos el flujo de OAuth si lo iniciamos.

Para hacerlo, Pied Piper puede generar una cadena aleatoria (la llamamos ), almacenarla en cookies y enviarla a Hooli. Hooli luego enviará esto de vuelta a Pied Piper cuando redirija a Big Head de regreso. Pied Piper debe verificar que lo recibido coincida con el de las galletas.statestatestate

• state=random_string_123: Una cadena generada aleatoriamente para evitar ataques CSRF.

Ataque #5: Espiar tokens de acceso

Endframe no se rinde. Se les ocurrió otro plan:

1. Se asociaron con un desarrollador genio llamado Jian Yang y crearon una herramienta de «perritos calientes o no» que detecta perritos calientes. Maliciosamente, también envía todo el historial del navegador a Endframe.
   • (Hay una serie de otros ataques de rastreo de historial o degradación de HTTP que también podrían lograr esto).
2. Big Head piensa que es divertido y lo instala.
3. Endframe ahora ve todos los tokens de acceso para todos los servicios con los que Big Head inició sesión, buscando URL que se parezcan a .https://piedpiper.com/callback?access_token=access_token_123

Hay una solución para esto. Necesitamos asegurarnos de que los tokens de acceso nunca se intercambien en las URL del navegador.

Hooli genera un «código de autorización» de corta duración y redirige a Pied Piper con este código. Pied Piper luego realiza una solicitud POST a otro punto final, que invalida el código de autorización y lo intercambia por el token de acceso.

De esta manera, el token de acceso nunca termina en el historial del navegador. A esto lo llamamos flujo de código de autorización. Es más seguro que el flujo implícito, pero aún no hemos terminado.

• response_type=code: Le dice a Hooli que estamos usando el flujo de código de autorización, en lugar del flujo implícito.
• code=authorization_code_123: El código de autorización que Hooli generó para Pied Piper.
• grant_type=authorization_code: Para el flujo de código de autorización, esto es siempre (no cubriremos los otros tipos de concesión).authorization_code

Ataque #6: Espionaje de códigos de autorización

Si Endframe escucha el código de autorización en tiempo real, pueden cambiarlo por un token de acceso muy rápidamente, antes de que lo haga el navegador de Big Head.

1. Big Head todavía tiene instalada la herramienta «Hot dog or not».
2. Tan pronto como Big Head conecta su cuenta de Hooli drive, «Hot dog or not» obtiene el código de autorización del historial del navegador de Big Head.
3. En tiempo real, más rápido de lo que el navegador de Big Head puede enviar la solicitud, Endframe se abalanza y envía una solicitud a Hooli con el código de autorización de Big Head. Obtienen el token de acceso y la solicitud de Big Head falla.

Actualmente, cualquier persona con el código de autorización puede cambiarlo por un token de acceso. Necesitamos asegurarnos de que solo la persona que inició la solicitud pueda hacer el intercambio.

Hacemos esto almacenando de forma segura un secreto en el cliente. Analizamos este secreto y se lo enviamos a Hooli junto con la primera solicitud. Al intercambiar el código de autorización para el token de acceso, enviamos el secreto original a Hooli. A continuación, Hooli compara los hashes, lo que demuestra que la solicitud procede del mismo cliente.

Este procedimiento se denomina clave de prueba para el intercambio de código (PKCE).

• code_verifier=random_string_456: La cadena aleatoria original Pied Piper enviada a Hooli.
• code_challenge=hashed_string_123: El verificador de código hash.

¿Es esto seguro? Casi…

Ataque #7: Manipulación de URI de redireccionamiento en URI de confianza

Imagine que Pied Piper tiene dos URI de redireccionamiento registrados:

• https://piedpiper.com/callback
• https://piedpiper.com/share-files-callback

El primero autoriza y comprime los archivos de la unidad Hooli, y el segundo comparte archivos públicamente con otros usuarios. (También podría ser el mismo punto de conexión con diferentes parámetros de consulta).

Aunque nos protegemos contra Endframe reemplazando el URI de redireccionamiento con algo totalmente malicioso (como ), si Endframe puede interceptar la solicitud de alguna manera, aún puede modificar el URI para que apunte al otro punto final.https://endframe.com

¿La solución? Haga que el cliente vuelva a enviar el URI actual al intercambiar el código de autorización para el token de acceso. A continuación, Hooli puede comprobar que el URI de redireccionamiento coincide con el de la solicitud original.

Algunas notas finales

Esta es una explicación informal del flujo de OAuth, y la especificación real es mucho más larga. Por ejemplo, los secretos de cliente, los tokens de actualización, el flujo de credenciales de cliente, las concesiones de tokens, etc., no se tratan aquí.

Además, hay muchos detalles esenciales que se requieren para una implementación segura. Probablemente no deberías implementar tu propio cliente de OAuth.

Para profundizar o si desea implementar OAuth en sus aplicaciones, aquí hay algunos buenos recursos.

• El marco de autorización de OAuth 2.0
• Modelo de amenazas de OAuth 2.0 y consideraciones de seguridad
• OAuth 2.0 para aplicaciones basadas en navegador

Y finalmente, si no desea implementar OAuth usted mismo, esa es exactamente la razón por la que creamos Stack Auth, puede obtener el inicio de sesión de OAuth de Google/Github/Microsoft/y más con solo alternar un interruptor.