Autenticación y autorización

Autenticación y autorización son conceptos distintos que se confunden con frecuencia. Esa confusión puede llevar a QA a describir mal los defectos y pasar por alto riesgos de acceso reales.

→La autenticación pregunta: «¿Quién eres?».
→La autorización pregunta: «¿Qué tienes permitido hacer?».

Introducir un usuario y una contraseña no concede acceso a todos los recursos o acciones. A la inversa, algunos recursos pueden estar disponibles sin iniciar sesión, pero solo de forma limitada. Prueba estas capas por separado.

Autenticación

La autenticación confirma la identidad de un usuario, servicio o dispositivo. El sistema determina si el sujeto es quien afirma ser.

→Nombre de usuario y contraseña
→Código de un solo uso
→MFA
→SSO
→Token de acceso o token de identidad
→Certificado
→Credenciales entre máquinas

La autenticación va más allá de iniciar sesión correctamente y abarca un ciclo de vida:

→Un usuario o sistema presenta una credencial
→El servidor la valida
→Se crea una sesión o se emite un token
→La credencial tiene un periodo de validez
→Puede caducar, revocarse, dañarse o utilizarse en un contexto incorrecto

Por tanto, las comprobaciones de autenticación suelen abarcar más que intentos de inicio de sesión válidos y no válidos.

Autorización

Una vez que el sistema identifica al sujeto, la autorización determina qué acciones permite.

→Un usuario normal solo puede ver sus propios pedidos
→Un responsable puede ver los pedidos de su equipo
→Un administrador puede cambiar los estados de los usuarios
→Un servicio de integración puede leer datos, pero no eliminarlos
→Un usuario anónimo puede abrir una página pública, pero no una zona de cuenta personal

La autorización evalúa permisos, roles, políticas, propiedad y restricciones de negocio, no la identidad.

Un usuario autenticado correctamente puede seguir sin tener permiso para una acción. Es una capa independiente de control de acceso, no un error de inicio de sesión.

Por qué se confunden

Desde fuera, sus fallos pueden parecer similares.

→El usuario no ha iniciado sesión
→Su token ha caducado
→Su token no es válido
→Ha iniciado sesión, pero no tiene el rol requerido
→Tiene el rol, pero intenta abrir un recurso de otra persona
→El backend comprueba mal el acceso

La interfaz puede representar todo esto como «acceso denegado» o «debes iniciar sesión». QA debe distinguir los defectos, sus causas y sus prioridades.

Comprobaciones de autenticación para QA

→Las credenciales válidas permiten iniciar sesión
→Las credenciales no válidas no permiten iniciar sesión
→Los tokens y las sesiones caducados se tratan correctamente
→El cierre de sesión funciona correctamente
→El cierre de sesión invalida la sesión según lo requerido
→El acceso no persiste más tiempo del previsto
→Recordarme, los tokens de renovación, MFA y SSO funcionan correctamente
→Las credenciales no se filtran a través de URL, almacenamiento local, registros o trazas de red
→Los inicios de sesión repetidos entre dispositivos o pestañas se comportan correctamente

Prueba todo el ciclo de vida de las credenciales además del recorrido correcto. Muchos defectos aparecen durante la renovación, caducidad, revocación y reutilización de tokens o sesiones, no en el inicio de sesión inicial.

Comprobaciones de autorización para QA

→Los usuarios solo pueden ver datos permitidos
→Los usuarios solo pueden realizar acciones permitidas
→El acceso se controla tanto en el backend como en la interfaz
→Los identificadores directos no permiten exponer recursos de otro usuario
→Los roles no tienen permisos excesivos
→Los botones ocultos de la interfaz no pueden seguir invocándose mediante la API
→Las reglas son coherentes entre las interfaces web, móvil y API
→Los cambios de rol, estado del usuario o estado del objeto no conceden permisos accidentalmente

Comprobar la autorización solo mediante la interfaz es una trampa habitual. Un botón oculto no demuestra que haya protección. Las pruebas eficaces de autorización casi siempre incluyen llamadas directas a la API o, al menos, la inspección de las respuestas del backend.

Fallos frecuentes

→Sustituir un ID en una solicitud expone los datos de otro usuario
→El token de un usuario anterior sigue funcionando después de cerrar sesión
→Un cambio de rol en la interfaz de administración no se aplica a tiempo
→Un servicio comprueba el rol, pero no la propiedad del objeto
→El frontend muestra acceso prohibido mientras el backend ejecuta la solicitud
→Un token de acceso sigue siendo válido más tiempo del esperado
→Los eventos críticos no revocan los tokens de renovación
→Los usuarios anónimos reciben más datos de los permitidos

Estos defectos suelen importar más para la calidad y la seguridad del producto que los problemas habituales de interfaz.

Ejemplo práctico

Considera un sistema de pedidos.

El usuario A inicia sesión y abre el pedido #1001; después cambia el ID de una solicitud de red o de la URL por #1002.

Si el sistema devuelve el pedido de otro usuario, la autenticación ya se ha completado correctamente. Ha fallado la autorización porque el backend no verificó la propiedad.

Es una comprobación crucial para QA. El inicio de sesión y la emisión de tokens pueden funcionar perfectamente y, aun así, un control débil del acceso a recursos deja el producto vulnerable.

Ideas clave para QA

→La autenticación y la autorización son capas independientes.
→La autenticación verifica la identidad; la autorización verifica el acceso.
→Iniciar sesión correctamente no permite realizar cualquier acción.
→Las restricciones de la interfaz necesitan aplicarse en el backend para ofrecer una protección fiable.
→El acceso a datos y acciones de otro usuario es un área de prueba esencial.
→Prueba los ciclos de vida de tokens, sesiones y roles con tanto cuidado como el inicio de sesión.

Lecturas adicionales

→En esta base de conocimientos: HTTP y HTTPS
→En esta base de conocimientos: JWT, OAuth 2.0 y claves de API
→Recurso externo: Guía de autorización de OWASP

Matriz de roles y propiedad para un ejercicio local

Separa la identidad del permiso para acceder a un objeto concreto. En el fixture didáctico local, el registro 1 pertenece al usuario A y el registro 2 al usuario B. Un usuario puede leer su propio registro; un administrador puede leer ambos. Las cadenas demo-user-a, demo-user-b y demo-admin son datos ficticios del ejercicio, no credenciales reales.

plain text

Identidad	Solicitud	Esperado
Sin token	GET /records/1	401 y WWW-Authenticate
Token desconocido	GET /records/1	401 y ningún dato del registro
Usuario A	GET /records/1	200, propietario a
Usuario A	GET /records/2	403, sin campos del propietario ni del registro
Usuario B	GET /records/2	200, propietario b
Administrador	GET /records/2	200, propietario b
Usuario A	POST /items con cuerpo válido	403 y ningún elemento nuevo

En el caso de un objeto prohibido, comprueba el cuerpo de la respuesta además del estado: un código de error acompañado de los datos de otro usuario sigue siendo un fallo. Una respuesta 401 se refiere a las credenciales; una 403 significa que se rechaza la operación. Un producto real puede utilizar 404 para ocultar la existencia del objeto, por lo que debes deducir las expectativas de su contrato. Este fixture utiliza deliberadamente 403.

El fixture no implementa inicio de sesión, verificación JWT, caducidad, revocación ni un almacén de sesiones. Prueba esos mecanismos por separado en un entorno autorizado; rechazar una cadena desconocida arbitraria no demuestra que funcione la caducidad de tokens.

Seguir aprendiendo

Descargar el laboratorio de práctica local (ZIP)

Mecanismos de tokens y credenciales

Escrituras negativas y efectos secundarios

MDN: respuesta 401