Cómo funciona OAuth: el flujo de código de autorización

Cómo funciona OAuth: el flujo de código de autorización

El lienzo interactivo de FlowJam de esta explicación: cada carril, cada fila y cada flecha de arriba forma parte de un diagrama real de QueryChart que puedes abrir y editar.

Cómo leer este diagrama

• Lee las tres columnas de izquierda a derecha: Autorización, Intercambio de token, Recurso protegido.
• Cada fila es la parte de la historia que le toca a un participante: la fila del usuario está arriba y la del servidor de recursos abajo, así el consentimiento del usuario y la validación del servidor enmarcan el centro.
• Las flechas que saltan de fila, como el código que vuelve al cliente, son mensajes de red reales entre las partes; las flechas dentro de una fila son los pasos propios de esa parte.

El baile de la autorización

«El usuario pulsa "Iniciar sesión con el proveedor"» empieza en la fila del usuario y traspasa a «El cliente redirige al usuario al servidor de autorización». La redirección es el movimiento que define a OAuth: saca al usuario FUERA de la aplicación cliente y lo lleva al proveedor, donde ocurre «El usuario inicia sesión y aprueba los ámbitos solicitados». La pantalla de consentimiento —no solo el inicio de sesión— es el paso que importa: el usuario elige exactamente qué puede hacer el cliente. «El servidor de autorización devuelve un código de autorización al cliente» devuelve el control a la aplicación, pero solo con un código, no con un token.

El intercambio de token

«El cliente intercambia el código y su secreto por un token de acceso» cruza de la fila del cliente a la del servidor de autorización. En este paso el cliente demuestra que es una aplicación legítima presentando el código que ha recibido Y su client secret registrado, así que un código robado por sí solo no basta. «El servidor de autorización emite el token de acceso» es el momento en que la decisión de consentimiento se convierte en una capacidad: una cadena que dice qué puede hacer el cliente y durante cuánto tiempo.

Gastar el token

«El cliente llama al servidor de recursos con el token de acceso» cruza al grupo «Servidor de recursos», y «El servidor de recursos valida el token y devuelve los datos del usuario» es la recompensa. El servidor de recursos no ve nunca la contraseña del usuario ni la pantalla de consentimiento: solo comprueba el token. «El usuario ve sus datos dentro de la aplicación» cierra el círculo de vuelta en la fila del usuario: desde su punto de vista, ha iniciado sesión una vez y la aplicación ha obtenido sus datos.

Relaciones clave y conclusiones

• La contraseña del usuario se entrega solo al servidor de autorización: ni el cliente ni el servidor de recursos la ven nunca.
• El consentimiento (los ámbitos) es la concesión real; el token de acceso es esa concesión en forma legible por una máquina.
• El código de autorización dura poco y no sirve de nada sin el client secret: dos factores protegen el intercambio.
• Los tokens de acceso caducan; los tokens de actualización acuñan otros nuevos sin volver a mostrar una pantalla de consentimiento.
• El único trabajo del servidor de recursos es validar el token, y eso mantiene desacopladas a las partes.

Cuándo usar este diagrama

• Explicar a un equipo de producto por qué «Iniciar sesión con Google» es seguro y qué pide la pantalla de consentimiento.
• Elegir un flujo de OAuth: el flujo de código de autorización de aquí frente a implicit o client credentials para otros escenarios.
• Auditar por dónde viajan de verdad las credenciales del usuario y los tokens en tu integración.

Cómo funciona

1. Renombra las partes según tu sistema

   Sustituye los cuatro grupos por tus participantes reales —tu aplicación web, tu proveedor de identidad, tu API— para que las fronteras reflejen el sistema que estás documentando.

2. Añade los ámbitos que solicitas

   Anota el paso del consentimiento con los ámbitos reales y una nota sobre por qué hace falta cada uno, para que quien revise vea la decisión de mínimo privilegio.

3. Dibuja la ruta de actualización

   Añade una rama después de la caducidad del token: el cliente presenta el token de actualización y recibe un token de acceso nuevo sin pantalla de consentimiento, terminando en su propio estado explícito.

4. Modela los casos de fallo

   Añade las ramas de rechazo —un consentimiento denegado, un código no válido, un token caducado o revocado— cada una con la respuesta de error que produce.

Preguntas frecuentes

¿Qué es OAuth y por qué existe?

OAuth es un estándar de delegación. Permite que una aplicación acceda a los datos de un usuario en otro servicio en nombre de ese usuario sin que la aplicación vea nunca su contraseña. El usuario se autentica una vez en el servidor de autorización y aprueba permisos concretos (los ámbitos); la aplicación recibe un token que puede gastar. Esa separación de responsabilidades es justo lo que representan los cuatro grupos del diagrama.

¿Cuál es la diferencia entre un código de autorización y un token de acceso?

Un código de autorización es un valor intermedio de vida corta que el cliente recibe tras el consentimiento del usuario; por sí solo no concede nada. El cliente intercambia el código —junto con su client secret registrado— por un token de acceso, que es la capacidad real con la que se llama al servidor de recursos. Ese intercambio en dos pasos es lo que permite al cliente demostrar su identidad en el endpoint del token.

¿Por qué el usuario no le da su contraseña a la aplicación?

Porque la aplicación solo necesita un acceso limitado y revocable: leer un perfil, no ser dueña de la cuenta. Si recibiera la contraseña tendría acceso total para siempre, y el usuario no podría revocar una aplicación sin cambiar la contraseña en todas partes. OAuth cambia una contraseña por un token acotado y con caducidad que el usuario puede revocar de forma independiente.

¿Qué son los ámbitos?

Los ámbitos (scopes) son los permisos concretos que concede el usuario, como «leer el correo» o «escribir en el calendario». Aparecen en la pantalla de consentimiento y quedan codificados en el token de acceso. El servidor de recursos los aplica, así que un token con ámbito de lectura no puede escribir: el mínimo privilegio está integrado en el protocolo en vez de depender del buen comportamiento del cliente.

Edita este diagrama en QueryChart (FlowJam)

Abre ese mismo lienzo del flujo de OAuth como tu propio diagrama, renombra las partes con tus servicios y anota los ámbitos que solicitas.

Edita este diagrama en QueryChart (FlowJam)