Autenticación y autorización

La autenticación establece la identidad. El sistema verifica que un usuario es quien dice ser, normalmente mediante credenciales como una contraseña, un token o un proveedor externo de identidad.

La autorización ocurre después de confirmar la identidad. El sistema evalúa si esa identidad tiene permiso para realizar una acción específica o acceder a un recurso particular.

Estas preocupaciones deben mantenerse separadas. La verificación de identidad no implica automáticamente derechos de acceso. Un usuario que ha iniciado sesión aún puede no tener permiso para ver ciertos datos o realizar acciones administrativas.

Conceptualmente: Usuario → Inicio de sesión → Identidad verificada → Comprobación de permisos → Acceso al recurso.

La autenticación ocurre primero. La autorización ocurre después, a menudo en cada solicitud.

La autenticación comienza cuando un usuario o sistema declara una identidad y presenta credenciales como prueba.

Nombre de usuario + contraseña es el método tradicional. El servidor comprueba las credenciales enviadas contra los datos de la cuenta almacenados.

Inicio de sesión OAuth delega la autenticación en un proveedor externo de confianza (como Google o GitHub), que devuelve una identidad verificada a la aplicación.

API Keys se usan comúnmente para la autenticación entre servidores, identificando aplicaciones en lugar de usuarios humanos.

Autenticación multifactor (MFA) refuerza la verificación de identidad al requerir una segunda prueba (como un código de un solo uso o un token de hardware).

Flujo conceptual: Inicio de sesión → Credenciales enviadas → El servidor verifica → Identidad confirmada.

Sin una identidad válida, la solicitud se detiene aquí.

En las aplicaciones web tradicionales, la autenticación se maneja usando sesiones del lado del servidor.

Cuando un usuario inicia sesión correctamente, el servidor genera un objeto de sesión que contiene información de identidad. Esta sesión se almacena en el servidor — comúnmente en memoria, una base de datos o una caché distribuida.

El servidor envía un ID de sesión de vuelta al cliente, normalmente almacenado en una cookie. En solicitudes posteriores, el navegador incluye automáticamente esa cookie.

El servidor lee el ID de sesión, recupera los datos de sesión correspondientes y determina la identidad del usuario.

La idea clave es simple: el servidor almacena el estado de la sesión. El cliente solo almacena una referencia a él.

En las APIs modernas y los sistemas distribuidos, la autenticación suele ser sin estado.

Después de un inicio de sesión exitoso, el servidor genera un token firmado que contiene información de identidad. Este token se devuelve al cliente.

Para cada solicitud posterior, el cliente incluye el token — normalmente como un Bearer token en el encabezado Authorization.

En lugar de buscar los datos de la sesión en un almacén del lado del servidor, el servidor verifica la firma del token y extrae directamente de él la identidad del usuario.

La diferencia clave con la autenticación basada en sesiones es que el servidor no mantiene el estado de la sesión para cada usuario. La verificación de identidad ocurre validando el propio token.

Este modelo simplifica la escalabilidad horizontal porque cualquier instancia del servidor puede validar el token sin almacenamiento compartido de sesiones.

Un JWT es una cadena estructurada compuesta por tres secciones codificadas en Base64 y separadas por puntos:

Header → metadatos sobre el token y el algoritmo de firma
Payload → claims (como el ID de usuario o el rol)
Signature → prueba criptográfica de que el token no fue alterado

Cuando un servidor emite un JWT, firma el token usando una clave secreta o una clave privada. Cuando el token se presenta más tarde, el servidor verifica la firma para asegurarse de que el payload no haya sido modificado.

Aclaración importante: los JWT no están cifrados por defecto. El payload puede ser decodificado por cualquiera que tenga el token. La firma solo garantiza integridad, no confidencialidad.

Los JWT son útiles porque permiten que la información de identidad viaje con la solicitud de una manera verificable sin requerir almacenamiento de sesión del lado del servidor.

Una vez que se confirma la identidad de un usuario, el sistema debe decidir qué acciones tiene अनुमति para realizar.

La autorización aplica las reglas de control de acceso. Incluso si un usuario está autenticado, puede no tener permiso para acceder a ciertos recursos o realizar determinadas operaciones.

Un modelo común es Role-Based Access Control (RBAC), donde a los usuarios se les asignan roles como “admin”, “editor” o “viewer”, y cada rol tiene permisos predefinidos.

Otro modelo es Attribute-Based Access Control (ABAC), donde las decisiones se toman en función de atributos como propiedades del usuario, propiedades del recurso o el contexto de la solicitud.

La autenticación normalmente ocurre una vez por sesión o por emisión de token. La autorización, en cambio, se evalúa en cada solicitud protegida para garantizar que las reglas de acceso se apliquen de forma consistente.

Cuando una solicitud llega al servidor, no ejecuta inmediatamente la lógica de la aplicación. Primero pasa por una capa de autenticación, normalmente implementada como middleware en frameworks como Express, Django o FastAPI.

Este middleware comprueba credenciales como una cookie de sesión o un token de autorización. Si las credenciales faltan o no son válidas, el servidor rechaza la solicitud con una respuesta 401 Unauthorized.

Si la identidad se verifica correctamente, el sistema evalúa entonces los permisos. Cuando el usuario no tiene acceso al recurso solicitado, el servidor devuelve 403 Forbidden.

Solo después de que pasan las comprobaciones de autenticación y autorización, la solicitud llega al handler y ejecuta la lógica de negocio, garantizando que las operaciones sensibles estén protegidas contra accesos no autorizados.

Incluso un flujo de autenticación implementado correctamente puede ser inseguro si faltan protecciones fundamentales.

Las contraseñas deben hashearse antes de almacenarse en una base de datos. El hashing garantiza que, incluso si la base de datos se ve comprometida, las contraseñas en bruto no queden expuestas.

Todo el tráfico de autenticación debe transmitirse sobre HTTPS. Sin cifrado en tránsito, las credenciales y los tokens pueden ser interceptados por atacantes.

Los access tokens deben tener tiempos de expiración. Los tokens de corta duración reducen el daño si un token es robado. Muchos sistemas usan refresh tokens para obtener nuevos access tokens sin que los usuarios tengan que iniciar sesión repetidamente.

La seguridad no se trata solo de verificar la identidad — se trata de proteger los mecanismos que verifican la identidad.