Autenticación vs autorización: qué cambia entre iniciar sesión y tener permisos
Publicado el 2026-10-20 por frfrand
Autenticación confirma quién sos y autorización decide a qué podés acceder: ejemplos, fallos y formas de probar permisos.
Autenticación es comprobar quién intenta acceder a una aplicación. Autorización es decidir qué puede hacer esa identidad. Son dos preguntas diferentes y confundirlas causa errores graves de seguridad.
Cuando iniciás sesión en un panel y escribís tu contraseña, el sistema intenta reconocer tu identidad. Una vez dentro, decidir si podés consultar la facturación de otro cliente es un problema distinto.
El ejemplo del edificio
Imaginá una empresa con recepción y varias oficinas. Para entrar, mostrás tu tarjeta de empleado: eso identifica quién sos. Pero la tarjeta no debería abrir automáticamente el despacho de dirección, el almacén y todos los archivos confidenciales.
La autorización establece esas restricciones. Una persona puede iniciar sesión correctamente y, aun así, recibir un error cuando intenta acceder a una función para la que no tiene permiso.
¿Qué mecanismos sirven para autenticarse?
Una contraseña, una llave de seguridad, una sesión válida o un sistema de inicio de sesión externo pueden participar en el proceso. También existen formas de combinar factores para dificultar el robo de cuentas.
Ningún método es perfecto. Una sesión puede ser robada, una contraseña reutilizada puede filtrarse y una integración mal configurada puede aceptar identidades que no debería.
Por eso importa también cómo se revocan sesiones y cómo se detectan accesos anómalos.
¿Cómo se aplica la autorización?
Una app puede utilizar roles como lector, editor o administrador. Pero en aplicaciones multicliente no alcanza con comprobar el rol: hay que validar a qué organización o recurso concreto pertenece el dato.
Por ejemplo, alguien puede ser administrador de la empresa A y no tener ningún acceso a la empresa B. Un endpoint que verifica únicamente role=admin y olvida comprobar la empresa puede exponer información de otros clientes.
El control tiene que ejecutarse del lado del servidor, no solo ocultando botones en el frontend.
Un caso típico: cambiar un ID en la URL
Imaginá que una API permite consultar una factura mediante /facturas/123. Una persona inicia sesión legítimamente y cambia el número por 124.
Si el backend devuelve una factura de otra cuenta sin comprobar el propietario, existe un problema de autorización. Es el tipo de error que puede ocurrir aunque la autenticación funcione perfectamente.
La solución consiste en aplicar permisos en cada operación y recurso sensible, y probar tanto casos permitidos como prohibidos.
¿Y qué pasa con un token válido?
Un token puede ayudar a identificar a una persona o cliente, pero válido no significa autorizado para todo. Hay que comprobar su alcance, expiración, audiencia y los permisos reales de la operación.
La autorización también puede cambiar durante una sesión: alguien pierde el acceso a un proyecto y el sistema necesita dejar de permitir acciones que antes eran legítimas.
Cómo probarlo antes de publicar
Prepará usuarios con distintos roles y organizaciones. Intentá acceder a los recursos que sí les pertenecen y luego a los que no. Comprobá que el servidor responde correctamente, sin filtrar datos privados.
No te quedes con la prueba de «el administrador puede abrir el panel». Es igual de importante comprobar que un lector no pueda borrar registros y que un usuario de una empresa no pueda consultar otra.
¿Dónde entra ArduMaker?
ArduMaker organiza proyectos y recursos por empresas y equipos. El principio es el mismo: reconocer una cuenta no basta; cada operación sobre un VPS, aplicación o dato debe respetar los permisos y el alcance empresarial correspondiente.
En resumen: autenticación responde «¿quién sos?». Autorización responde «¿podés hacer esto?». Una aplicación necesita las dos y debe comprobar la segunda en cada acceso sensible.
Fuentes: OWASP Authorization Cheat Sheet · OWASP Authentication Cheat Sheet.