Proteger una API con Auth0 implica algo más que iniciar sesión: requiere que el authorization server reconozca el recurso externo y emita un access token con la audiencia correcta. Aquí verás cómo registrar una API en el dashboard de Auth0, qué papel juega cada actor del flujo OAuth y por qué un proxy server sin protección expone tus recursos.

¿Qué diferencia hay entre autenticación y autorización en Auth0?

Hasta ahora, la aplicación Failr solo implementaba autenticación: identificar al usuario mediante Universal Login y proteger las rutas de Next.js. Eso resuelve quién entra, pero no qué puede hacer una vez dentro.

Cuando inicias sesión con GitHub, Auth0 devuelve una sesión y un ID token. Ese token sirve para confirmar identidad, no para acceder a APIs externas. Y aquí aparece el problema real.

¿Qué es un ID token y para qué sirve? Es el token que Auth0 emite tras autenticar al usuario. Confirma identidad y entrega datos como profile y email, pero no autoriza el acceso a recursos protegidos.

La app Failr no es solo Next.js. Tiene además un proxy server en Express que sirve imágenes en el puerto 8080, como si fuera una API externa. Y esa API no está protegida [3:45].

¿Cuáles son los cuatro roles del flujo OAuth?

En cualquier flujo OAuth hay cuatro actores y conviene tenerlos claros antes de tocar el dashboard.

• Client: la aplicación Next.js que solicita acceso.
• Authorization server: Auth0, que emite los tokens.
• Resource owner: el usuario, es decir, tú.
• Resource server: el proxy server que sirve las imágenes.

En servicios como Spotify, el authorization server y el resource server viven juntos, así que se conocen. En cambio, al tercerizar la autorización con Auth0, hay que avisarle explícitamente que existe un resource server aparte [2:30].

¿Qué flujo aplica el SDK de Auth0 con Next.js?

El SDK implementa authorization code flow con PKCE (Proof Key for Code Exchange). Es un flujo complejo que el SDK resuelve por ti, aunque entender lo que ocurre por detrás te salva en escenarios donde toca implementarlo manual.

Cuando le das clic a conectar, Auth0 muestra la pantalla de Request Consent: pide permiso para acceder a tu profile y email. Al autorizar, entregas el authorization grant y Auth0 procede a emitir el token correspondiente.

¿Por qué necesitas un access token y no solo un ID token?

El ID token prueba quién eres. El access token prueba que tienes permiso de entrar a un recurso específico. Para proteger el proxy server, Auth0 debe emitir un access token cuya audience sea precisamente esa API.

Una vez emitido, mandas el token en el encabezado Authorization: Bearer y el resource server valida y responde. Sin ese paso, ocurre lo que se demuestra en la app: cierras sesión, copias la URL de la imagen, la abres en otra pestaña y el servidor la sirve igual, porque no sabe nada del contexto de autenticación [5:50].

¿Qué es la audience en un access token? Es el identificador de la API a la que el token concede acceso. Auth0 incluye ese valor en el token y el resource server lo verifica antes de responder.

¿Cómo registrar una API en el dashboard de Auth0?

El registro es directo. En el menú lateral entras a Applications y luego a APIs, y creas una nueva. Estos son los datos que necesitas:

1. Name: Proxy Server API. Es solo para identificarla dentro del dashboard.
2. Identifier: una URL ficticia que actuará como audience. En este caso, image.failr.com simulando un dominio real.
3. Signing Algorithm: lo dejas con el valor por defecto.

El identifier no necesita ser una URL real ni resoluble. Es una etiqueta única que Auth0 incrustará en el access token como audience y que tu resource server validará después [7:15].

¿Qué son los scopes y por qué definirlos desde el inicio?

Los scopes son permisos granulares que la API expone. Cada vez que un cliente pide un access token, puede solicitar uno o varios scopes, y la API decide qué entrega.

En la pestaña Permissions de la API recién creada, agregas un scope llamado read:images. Ese permiso lo controlas más adelante para que cualquier cliente que pida acceso a la API pueda demostrar que tiene autorización para leer imágenes.

Definir scopes desde el principio te ahorra refactorizar cuando la API crezca y necesite distinguir, por ejemplo, entre leer y escribir.

¿Cuándo conviene proteger una API y qué riesgos corres si no lo haces?

Cualquier API que sirva datos sensibles, recursos privados o acciones con efectos secundarios debería estar protegida. El caso del proxy server lo demuestra: sin validación, basta conocer la URL para saltarse el login completo.

Login equivale a autenticación. Protección de APIs equivale a autorización. Son capas distintas y ambas hacen falta cuando tu arquitectura tiene más de un servicio.

Reto: en los comentarios, cuéntame en qué momentos crees que debería validarse una API y cómo lo harías sin Auth0. ¿Implementarías JWT manual, sesiones compartidas, API keys?