Explicación del protocolo OAuth2

Veamos qué es el protocolo OAuth 2.0 y cómo funciona, a través de ejemplos prácticos 😉.

Introducción

OAuth 2 es un protocolo de autorización:

• Diseñado para permitir que una aplicación cliente acceda a recursos alojados por otras aplicaciones.
• Significa "Open Authorization".

Ejemplo

Cuando inicias sesión en una app usando Google, la aplicación no obtiene tu contraseña de Google en ningún momento.

En vez de eso:

• La aplicación le pide a Google permiso para acceder a tus datos (como tu correo).
• Google te pregunta si concedes el permiso.
• Si estás de acuerdo, Google le da a la aplicación un token — una llave especial que representa al permiso pero sin revelar tu contraseña.
• La app usa el token para llamar a la API de Google a nombre tuyo.

Así puedes otorgar acceso a tus datos (o a ejecutar acciones a tu nombre), a través de servicios como Facebook, GitHub, Twitter, Steam, BitBucket, LinkedIn y muchos más.

Este es posiblemente el uso más común.

Pero no es el único.

• OAuth 2 provee un flujo de autorización para aplicaciones web, aplicaciones móviles e incluso programas de escritorio.
• También permite la comunicación entre servicios backend (conocido como machine to machine).

En el primer caso, existe un usuario humano, también conocido como end user, o usuario final.

En el segundo caso no, y puede tratarse de un cron job ejecutando un script que se comunica con una API interna, o incluso un worker consumiendo un microservicio en una red privada.

Roles en OAuth

En el protocolo que define OAuth podemos identificar 4 roles.

• Client
• Resource Owner
• Resource Server
• Authorization Server

Veamos en qué consiste cada rol.

💻 Client

Es la aplicación cliente que quiere acceder a un recurso determinado, u obtener permisos.

Cuando se trata de una aplicación de cara al usuario final, dicho usuario debe conceder los permisos.

Cuando se trata de una comunicación "máquina a máquina", la aplicación cliente es el servidor o servicio que inicia la comunicación.

🙇 Resource Owner

El "dueño del recurso" es el usuario que autoriza a una aplicación, para que pueda acceder a sus datos o ejecutar acciones a su nombre.

El acceso está determinado en función del "scope" que concede el usuario durante la autorización.

🔑 Authorization Server

Resource server es el servidor que almacena las cuentas de usuarios, y authorization server es el servidor que verifica la identidad de los usuarios y emite access tokens a la aplicación cliente.

Es el servidor que emite los tokens (access token, refresh token) tras verificar las credenciales.

📦 Resource Server

Es el API o servicio que protege recursos (datos, endpoints).

Recibe el token del cliente y lo valida (normalmente contra el authorization server o con claves públicas).

Si el token es válido y tiene los permisos adecuados (scopes), devuelve los datos solicitados.

Flujos del protocolo OAuth

OAuth2 define múltiples flujos.

Cada uno designado para un escenario específico, según el tipo de cliente:

👤 Authorization Code Flow

Para aplicaciones web y móviles que cuentan con un backend.

La app cliente obtiene un authorization code (via browser redirect), y luego lo intercambia por un token.

Es seguro ya que el intercambio ocurre en el servidor.

📱 PKCE

PKCE es una variante, que agrega seguridad extra para aplicaciones orientadas al usuario final (web, SPA, móvil).

🤖 Client Credentials Flow

Para la comunicación machine to machine,

• también conocida como service-to-service,
• o servidor a servidor:

El cliente se autentica con su propio ID y secret (sin intervención de un usuario humano).

📺 Device Authorization Flow

Para dispositivos que no cuentan con browsers o teclados (como las smart TVs).

El usuario inicia sesión en otro dispositivo; y el dispositivo donde se quiere iniciar la sesión hace polling hasta que se complete.

Qué significa

Que podemos encontrar diferencias en función al authorization grant type.

Es decir, OAuth puede implementarse bajo diversas condiciones, y varía principalmente si se trata de una aplicación cliente pública o no.

🧠 Cómo funciona OAuth2 paso a paso

Hoy analizaremos más a detalle cómo funciona el flujo "Authorization Code Flow" desde una aplicación web:

1. La aplicación cliente solicita una autorización para acceder a los recursos de un usuario, en un servicio determinado.

2. Si el usuario autoriza esta solicitud, la aplicación recibe el consentimiento a través de un authorization code.

3. La aplicación cliente solicita un access token al authorization server, demostrando que es un cliente válido (con sus credenciales), y presentando el código que recibió anteriormente.

4. Si la identidad de la aplicación cliente se valida adecuadamente por el servicio, y código de autorización es válido, el authorization server emite un access token a la aplicación cliente. ✅ Con esto la autorización se ha completado.

5. La aplicación cliente puede presentar el access token recibido en el paso anterior, y "solicitar un recurso" al resource server.

6. Si el access token es válido, el resource server hace entrega del recurso a la aplicación.

Es importante tener en cuenta que con "recurso" nos referimos generalmente a acceder a información del usuario.

Pero si el resource server lo permite (y el usuario lo ha autorizado), también es posible ejecutar acciones a nombre del usuario.

Nota:

• Puedes volver a leer los pasos anteriores y considerar al authorization server y resource server como una misma API.
• Ya que usualmente cuando un servicio (como Facebook o Google) implementa un servidor de OAuth2, pone a disposición a nuestra disposición una API que desempeña ambos roles.

Explicación del protocolo OAuth con un ejemplo

Veamos cómo funciona OAuth, descrito muy de cerca, a través de un ejemplo.

Imaginemos que queremos iniciar sesión vía Facebook.

En ese caso, se inicia la siguiente secuencia.

• Un usuario entra a nuestra página (digamos que nuestra página se llama Programación y más), y hace clic en "Ingresar usando Facebook".

• Nuestra aplicación lo va a redirigir a una URL como la siguiente: facebook.com/oauth2/auth?client_id=ABC&redirect_uri=programacionymas.com/oauth_response

  Ésta URL contiene: un client_id, una redirect_uri y usualmente un parámetro scopes (para indicar a qué información queremos acceder).

• Facebook primero va a ver si nuestro client_id es válido (comparándolo con su lista de oauth_client permitidos).

• Si todo está correcto, entonces define una variable de sesión que guarda nuestro client_id y redirect_uri. Y entonces:

  • Redirige al usuario a facebook.com/login (muestra un formulario de inicio de sesión) si el usuario aún no ha iniciado sesión.
  • O avanza directamente al siguiente paso si ya tiene una sesión activa en Facebook.

• Facebook muestra el logo de Programación y más y el nombre de la app (lo reconoce a partir del client_id), indicando al usuario: "Esta app quiere acceder a tus datos, ¿le das permiso?" (según el scope indicado previamente).

Si aceptamos, entonces:

• Facebook genera un código (que tiene un sólo uso válido para Programación y más, el usuario en cuestión y el scope solicitado).

• Facebook redirige al usuario según la redirect_uri indicada al inicio.

• Esta redirect_uri es una ruta usada como callback en nuestra aplicación para recibir el código otorgado por Facebook, y así permitir el inicio de sesión.

• Por ejemplo, Facebook enviará el código generado hacia PyM de esta manera: programacionymas.com/oauth_response?code=aquí_el_authorization_code.

• PyM toma el código que recibe de Facebook y vuelve a hacer una petición a Facebook, incluyendo ahora su id y secret.

• Esta petición no se trata de una redirección a nivel de navegador, sino más bien de una solicitud de servidor a servidor.

• Para probar su identidad, PyM hace una petición de esta forma: facebook.com/oauth2/token?client_id=ABC&client_secret=XYZ&code=aquí_el_código

• Facebook verifica que el código sea válido, y así mismo lo invalida en ese instante (ya que son de uso único).

• Entonces Facebook responde con un access_token, que PyM podrá usar (hasta que expire) para hacer peticiones a la API, a nombre del usuario que ha otorgado los permisos.

Por ejemplo:

• Con este token podemos acceder a la información básica del usuario, y usar estos datos para crear una cuenta en nuestro propio servidor.
• Pero un token, dependiendo de la API, nos permite también realizar acciones a nombre del usuario, en función a los permisos otorgados.
• El scope indicado inicialmente determina los permisos que estamos solicitando al usuario.

Preguntas frecuentes

Por qué es necesario un authorization code

Pregunta:

¿Por qué Facebook le pasa un código de uso único a la aplicación cliente y no el access_token directamente?

Respuesta:

Porque Facebook necesita validar que realmente PyM ha solicitado el acceso.

El client_id suele ser un dato que está expuesto (es público, ya que forma parte de la URL de Facebook, a donde el usuario es redirigido desde un inicio).

Cualquiera podría hacer una petición usando dicho client_id.

Pero existe un client_secret que sólo PyM posee, y es justamente lo que se valida en este punto.

Nota:

Si un "hacker" roba este dato (el client_secret de una aplicación), podría tener los mismos permisos que fueron otorgados a esta aplicación cliente por parte de sus usuarios.

Entonces Facebook debe asegurar que quien solicitó los "recursos" sea el mismo que va a acceder a ellos.

Y aquí es donde PYM se identifica ante Facebook con su client_id y client_secret.

¿Por qué el authorization code no se envía directamente al backend?

Pregunta:

En vez de redirigir a una URL que contiene el authorization code como parámetro, ¿por qué no Facebook lo envía a PyM directamente, de servidor a servidor?

Respuesta:

Cuando Facebook redirige al usuario a una ruta de PyM, lo hace principalmente para ceder el control del flujo a la aplicación cliente.

Es decir, todos queremos que la aplicación cliente continúe con el usuario, según lo que éste intentaba hacer inicialmente, ¿verdad?

Así, una vez que el usuario ha otorgado los permisos necesarios, la aplicación cliente y el usuario pueden continuar donde se quedaron ✅.

Referencias

• Digital Ocean: An Introduction to OAuth 2, por Mitchell Anicas
• OAuth 2 Explanation, por Michael Ziwisky

# oauth