Cada vez que inicias sesión en una aplicación, ocurren dos procesos distintos que a menudo se confunden: la autenticación y la autorización. Entender la diferencia es una de las bases del desarrollo backend y de la seguridad de cualquier sistema, desde una tienda en línea hasta una app bancaria.
Dos preguntas diferentes
La forma más sencilla de recordarlo es pensar en un edificio de oficinas:
- Autenticación: responde a “¿quién eres?”. Es el momento en que muestras tu credencial en la entrada para demostrar tu identidad.
- Autorización: responde a “¿qué puedes hacer?”. Aunque ya estés dentro, tu tarjeta quizá solo abra algunas puertas y no otras.
En una aplicación, la autenticación verifica que el usuario es quien dice ser, normalmente con correo y contraseña. La autorización decide, una vez identificado, a qué datos y acciones tiene acceso: ver su propio perfil, editar un producto o administrar a otros usuarios.
| Concepto | Pregunta que responde | Ejemplo | Cuándo ocurre |
|---|---|---|---|
| Autenticación | ¿Quién eres? | Iniciar sesión con contraseña o código | Al entrar al sistema |
| Autorización | ¿Qué puedes hacer? | Acceder al panel de administración solo si eres administrador | En cada petición protegida |
Cómo se autentica un usuario
Los métodos de autenticación se suelen agrupar por el tipo de prueba que piden:
- Algo que sabes: una contraseña o un PIN.
- Algo que tienes: un teléfono que recibe un código o una llave de seguridad física.
- Algo que eres: una huella dactilar o el reconocimiento facial.
Combinar dos o más de estas categorías se llama autenticación multifactor y reduce mucho el riesgo si una contraseña se filtra. Además, las contraseñas nunca deben guardarse en texto plano: se almacenan transformadas con funciones de hash diseñadas para este fin, como bcrypt o Argon2, que dificultan que alguien las recupere aunque acceda a la base de datos.
¿Y después de iniciar sesión? Sesiones y tokens
El protocolo HTTP no recuerda nada entre una petición y la siguiente. Por eso, tras autenticarte, el servidor necesita una forma de reconocerte en cada solicitud sin pedirte la contraseña cada vez. Existen dos enfoques habituales.
Sesiones en el servidor
El servidor crea un registro de sesión y entrega al navegador un identificador, normalmente dentro de una cookie. En cada petición, el navegador envía esa cookie y el servidor consulta su registro para saber quién eres. Es un modelo sencillo y fácil de invalidar: si quieres cerrar una sesión, basta con borrar el registro.
Tokens firmados
En lugar de guardar un registro, el servidor entrega un token firmado que contiene la información necesaria. El cliente lo envía en cada petición, normalmente en la cabecera Authorization, y el servidor solo comprueba que la firma sea válida. Este enfoque encaja bien con APIs y aplicaciones móviles.
Qué es un JWT
El formato de token más conocido es el JWT (JSON Web Token). Se compone de tres partes separadas por puntos:
- Cabecera: indica el tipo de token y el algoritmo de firma.
- Carga útil (payload): contiene datos llamados “claims”, como el identificador del usuario, su rol y la fecha de expiración.
- Firma: permite verificar que el token no fue modificado.
Un detalle importante que se malinterpreta a menudo: el contenido de un JWT está codificado, no cifrado. Cualquiera que tenga el token puede leer su carga útil. La firma solo garantiza que nadie la alteró. Por eso nunca debes incluir contraseñas ni datos sensibles dentro de un JWT.
Cómo funciona la autorización
Una vez que el sistema sabe quién eres, debe decidir qué te permite hacer. Hay modelos muy usados:
- Control por roles (RBAC): cada usuario tiene uno o varios roles, como “lector”, “editor” o “administrador”, y cada rol tiene permisos asociados.
- Permisos específicos: se asignan acciones concretas, como “crear artículo” o “borrar comentario”, a cada usuario o grupo.
- Propiedad del recurso: un usuario puede editar solo lo que le pertenece, como sus propios pedidos.
La regla de oro es validar la autorización siempre en el servidor. Ocultar un botón en la interfaz no protege nada: cualquier persona puede enviar una petición directa a la API, así que el backend debe comprobar los permisos en cada operación.
Códigos de respuesta que debes conocer
| Código | Significado | Cuándo se usa |
|---|---|---|
| 401 | No autenticado | Faltan credenciales o el token no es válido |
| 403 | Prohibido | El usuario está identificado, pero no tiene permiso |
Buenas prácticas básicas
- Usa siempre HTTPS para que credenciales y tokens no viajen en claro.
- Haz que los tokens caduquen en poco tiempo y renueva el acceso con un mecanismo controlado.
- Aplica el principio de mínimo privilegio: cada usuario recibe solo los permisos que necesita.
- Limita los intentos de inicio de sesión para frenar los ataques de fuerza bruta.
- No programes tu propio sistema criptográfico: apóyate en bibliotecas y servicios probados.
Un ejemplo completo del flujo
Imagina una API de una tienda en línea. Primero, el usuario envía su correo y contraseña a una ruta de inicio de sesión. El servidor comprueba el hash de la contraseña y, si coincide, responde con un token. A partir de ahí, cada petición incluye ese token. Cuando el cliente intenta ver sus pedidos, el servidor verifica la firma (autenticación) y confirma que esos pedidos pertenecen a ese usuario (autorización). Si intentara abrir el panel de administración sin el rol adecuado, recibiría un 403.
Conclusión
Autenticar es comprobar la identidad; autorizar es decidir qué permite esa identidad. Con sesiones o tokens como JWT, y con permisos siempre validados en el servidor, puedes construir aplicaciones más seguras. Si quieres profundizar en estos conceptos de forma práctica, descubre los cursos de desarrollo backend y de seguridad de la información de Cursa.
