Proteger un endpoint privado con un token es la forma más tradicional de controlar quién accede a qué dentro de una API. Aquí aprendes cómo funciona el flujo entre cliente y servidor cuando usas autorización tipo Basic y Bearer, por qué necesitas HTTPS y qué rol cumple el token como tarjeta de acceso temporal.

Esta guía te sirve si estás construyendo una API en Node.js con Express, si quieres entender qué pasa detrás de un formulario de login, o si te preparas para temas más avanzados como JSON Web Tokens y Open Authorization.

¿Qué pasa cuando llamas a un endpoint público y a uno privado?

La diferencia entre ambos se nota desde la primera petición HTTP. Cuando haces un request a un endpoint público, el servidor responde directamente con un 200 OK y el contenido. No hay validación, no hay credenciales, no pasa nada raro.

Cuando llamas a un endpoint privado sin credenciales, el servidor te responde con un error 401, que significa no autorizado. Ese código te indica que el recurso existe, pero necesitas demostrar quién eres antes de acceder.

¿Qué significa el error 401 en una API? Significa que el cliente no envió credenciales válidas o no envió ninguna. El servidor reconoce el endpoint, pero exige autenticación antes de devolver el contenido.

¿Cómo se obtiene un token con autorización Basic?

Para acceder al recurso privado primero pides un token. Eso se hace con una petición POST al endpoint /token usando autorización tipo Basic. En este tipo de autorización envías usuario y contraseña concatenados con dos puntos y codificados en base64 [02:00].

El servidor valida esas credenciales contra su base de datos y, si todo cuadra, te devuelve un token. Ese token funciona como una medalla o tarjeta de acceso que usarás en las siguientes peticiones.

Un detalle clave: la codificación en base64 no es encriptación. Es un proceso reversible, cualquiera con el header puede decodificarlo y leer tu usuario y contraseña. Por eso la autorización Basic siempre debe viajar sobre HTTPS, nunca sobre HTTP plano.

¿Cómo accedes al endpoint privado con autorización Bearer?

Una vez tienes el token, cambias el tipo de autorización. Ya no envías usuario y contraseña, sino el token dentro de un header tipo Bearer. El servidor recibe ese token, lo verifica, comprueba que no esté expirado y, si todo está en orden, responde con el contenido privado.

¿Cuál es la diferencia entre Basic y Bearer? Basic envía usuario y contraseña codificados en base64 para autenticarte. Bearer envía un token que ya prueba que estuviste autenticado antes, sin volver a exponer credenciales.

¿Cómo se implementa este flujo en Express?

El ejemplo usa un servidor Express escrito en Node.js corriendo en el puerto 3000 [05:30]. El archivo index carga las variables de entorno al inicio porque hay secretos que no deben quedar expuestos en el código.

Dentro del archivo se definen tres endpoints:

• /public: responde directamente con I am public.
• /token: recibe credenciales Basic, valida el usuario y emite un token firmado.
• /private: exige un token Bearer, lo verifica y responde con I am private.

La función getCredentials toma el request, extrae el header de autorización, hace un split para separar el tipo (Basic) del valor codificado y devuelve el usuario y la contraseña ya decodificados [07:15]. Si ese header no existe, lanza el error que viste antes.

¿Cómo se valida el token en el endpoint privado?

En /private el flujo es similar pero con Bearer. Si el header falta o el tipo no es el adecuado, devuelves un error. Si todo está bien, extraes la cadena del token y pasas a la fase de verificación.

Verificar el token es indispensable. Sin esa validación, cualquiera podría llegar con un token inventado y hacerse pasar por un usuario legítimo. Después de verificar la firma, también revisas el tiempo de expiración: comparas la fecha de expiración guardada en el token con la fecha actual y, si ya pasó, rechazas la petición.

¿Cómo pruebas el flujo completo en Postman?

Postman simplifica todo el proceso. Para /public basta un GET a localhost:3000/public y obtienes la respuesta. Para /token configuras una autorización tipo Basic Auth, donde Postman toma el usuario y la contraseña, los concatena con dos puntos, los codifica en base64 y arma el header por ti.

Un truco útil: en la pestaña Tests de Postman puedes capturar el token de la respuesta y guardarlo como variable de entorno [10:45]. Así no tienes que copiarlo y pegarlo manualmente en cada nueva petición. Después, en /private, cambias el tipo de autorización a Bearer Token y referencias esa variable.

¿Por qué usar variables de entorno en Postman? Te permiten reutilizar valores como tokens, usuarios o URLs entre peticiones sin exponerlos visualmente y sin copiarlos a mano cada vez.

¿Qué limitaciones tiene este esquema de tokens?

Aunque el flujo funciona bien, tiene puntos débiles que conviene tener claros:

1. Necesitas autenticar al usuario tú mismo antes de emitir el token, lo que obliga a mantener tu propia base de datos de credenciales.
2. El tiempo de expiración debe ser corto, porque mientras el token sea válido, el cliente puede hacer lo que quiera sin volver a probar identidad.
3. No escala bien con terceros: si quieres confiar en usuarios autenticados por otro servicio, este modelo se queda corto.

Esa última limitación es justo lo que resuelve Open Authorization, donde delegas la autenticación a un proveedor externo en el que confías.

Ahora te toca a ti: dibuja el diagrama de flujo de un endpoint que quieras proteger. ¿Usarías token, sesiones, una palabra secreta? Puedes apoyarte en swimlanes.io o la herramienta que prefieras, y déjame tu propuesta en los comentarios.