Proteger una aplicación con login es solo la mitad del camino. Cuando tu arquitectura incluye un servidor externo que sirve recursos —como imágenes, datos o archivos—, ese servidor también necesita saber quién tiene permiso de acceder. Auth0 permite registrar APIs en su dashboard para que el sistema de autorización las reconozca y emita los tokens adecuados. A continuación se explica paso a paso cómo funciona este proceso y por qué es fundamental.
¿Cuál es la diferencia entre autenticación y autorización en Auth0?
Hasta este punto, la aplicación Fabler implementa autenticación: identifica al usuario y protege el acceso mostrando el universal login cada vez que alguien intenta entrar sin sesión [0:20]. Auth0 devuelve un ID token que confirma la identidad del usuario.
Sin embargo, la aplicación también cuenta con un proxy server en Express que sirve imágenes en el puerto 8080 [1:07]. Este servidor actúa como una API externa y no está protegido: cualquier persona puede acceder a las imágenes directamente, incluso sin sesión activa [5:04]. Ahí es donde entra la autorización, que consiste en determinar si un usuario autenticado tiene permiso para consumir un recurso específico.
- Autenticación: verificar la identidad del usuario (quién eres).
- Autorización: verificar los permisos del usuario (qué puedes hacer).
¿Cómo funciona el flujo de OAuth con cuatro roles?
El estándar OAuth define cuatro roles que interactúan en cada flujo de autorización [1:47]:
- Cliente: la aplicación de Next.js que solicita acceso.
- Authorization server: Auth0, que emite los tokens.
- Resource owner: el usuario final, es decir, tú.
- Resource server: el proxy server que sirve las imágenes.
Cuando usas un servicio como Spotify, el authorization server y el resource server suelen pertenecer a la misma entidad, así que se conocen mutuamente [2:17]. Al tercerizar la autorización con Auth0, es necesario informarle explícitamente que existe un resource server que debe protegerse.
El SDK de Auth0 para Next.js implementa internamente el authorization code flow con PKCE (Proof Key for Code Exchange) [2:47]. Este flujo incluye la pantalla de request consent, donde el usuario acepta compartir su perfil y correo electrónico [3:17]. Tras la autorización, Auth0 devuelve no solo el ID token, sino también un access token cuya audience apunta a la API que queremos proteger [4:10]. Ese token se envía en el encabezado Authorization: Bearer en cada petición al servidor.
¿Qué pasos seguir en el dashboard de Auth0?
Registrar la API es un proceso rápido [5:30]:
- Ir a Applications → APIs en el dashboard de Auth0.
- Crear una nueva API con un nombre descriptivo, por ejemplo
proxy server API.
- Asignar un identifier que funcione como audience. Puede ser una URL ficticia como
image.fabler.co [6:00]. Este valor es el que Auth0 incluirá en el access token.
- Dejar el algoritmo de firmado por defecto.
- Dar clic en crear.
¿Cómo configurar permisos y scopes en la API?
Una vez creada la API, se pueden definir scopes en la pestaña de permissions [6:30]. Un scope representa un permiso granular; por ejemplo:
read:images — permite leer las imágenes servidas por el proxy.
Este permiso se valida después en el servidor para asegurar que quien envía el access token realmente tiene derecho a consumir el recurso. De esta forma, Auth0 sabe que existe una API externa y puede emitir tokens con la audiencia y los permisos correctos.
¿Por qué es esencial el concepto de audience en el access token?
El identifier que configuraste al crear la API se convierte en el campo audience dentro del access token [7:02]. Esto le dice al resource server: "este token fue emitido específicamente para ti". Sin ese dato, el proxy server no tendría forma de saber si el token es legítimo o si fue generado para otro servicio.
En resumen, el flujo completo queda así: el usuario inicia sesión, Auth0 emite un access token con la audience del proxy server y los scopes definidos, y la aplicación envía ese token en cada petición al servidor de imágenes.
Ahora es tu turno: comparte en los comentarios cuándo consideras necesario validar una API y cómo lo resolverías sin Auth0.
