Autenticación y autorización en Postman aplicada a flujos de QA

Conceptos operativos: autenticación vs autorización en QA

Autenticación responde a “¿quién eres?” (credenciales, tokens, sesión). Autorización responde a “¿qué puedes hacer?” (roles, permisos, scopes/alcances, claims). En flujos de QA, ambas se prueban con: (1) requests válidos (happy path), (2) credenciales inválidas, (3) token expirado, (4) permisos insuficientes, (5) rotación/revocación, (6) validación de claims/scopes cuando el backend los expone.

Buenas prácticas en Postman para manejar secretos (sin hardcodeo)

• Guarda secretos en variables (Environment o Vault) y referencia con {{variable}}.
• Evita pegar tokens en headers manualmente; captura y reutiliza desde scripts.
• Usa Current Value para ejecutar localmente sin exponer valores en exportaciones; deja Initial Value vacío si el archivo se compartirá.
• Centraliza credenciales por entorno: baseUrl, client_id, client_secret, username, password, apiKey.
• Si tu equipo usa Postman Vault, coloca allí secretos sensibles (client_secret, passwords) y deja el Environment para valores no sensibles.

API Keys (header y query) en pruebas

Cuándo se usa

Común en integraciones server-to-server o APIs internas. Suele ser un identificador/llave estática, a veces con rotación. No suele representar un usuario, sino una aplicación.

Implementación en Postman

• En header: agrega x-api-key: {{apiKey}} o el nombre que defina tu API.
• En query: agrega ?api_key={{apiKey}} o similar.

Checks de QA recomendados

• Key faltante: espera 401 o 403 según el diseño.
• Key inválida: espera 401/403 y mensaje consistente.
• Rotación: valida que una key nueva funcione y la anterior falle tras el periodo definido.

Ejemplo de test

pm.test('Debe rechazar si falta API key', function () {  pm.expect(pm.response.code).to.be.oneOf([401,403]);});

Basic Auth (usuario/contraseña) aplicado a QA

Cuándo se usa

Frecuente en endpoints internos, entornos de staging, o como capa adicional (por ejemplo, gateway). En HTTP, se envía como header Authorization: Basic ....

Configuración en Postman

1. En la request, ve a la pestaña Authorization.
2. Selecciona Type: Basic Auth.
3. Completa Username y Password usando variables: {{basic_user}} y {{basic_pass}}.
4. Postman generará el header automáticamente.

Casos de prueba

• Credenciales inválidas: 401.
• Usuario válido sin permiso: 403 (si aplica autorización por roles).
• Bloqueo por intentos (si existe): valida respuesta y headers de rate limit.

Bearer Tokens (JWT u opacos): uso práctico en colecciones

Qué es y cómo se usa

Un Bearer token se envía en Authorization: Bearer <token>. Puede ser JWT (con claims visibles) u opaco (solo el servidor lo entiende). En QA, lo importante es automatizar su obtención y validar expiración/permisos.

Configuración recomendada

1. En la colección (nivel raíz), define Authorization como Bearer Token.
2. En el campo Token, usa {{access_token}}.
3. En requests específicas que no requieren auth (por ejemplo, login), configura No Auth para que no hereden el Bearer.

OAuth 2.0 en Postman: conceptos operativos para QA

Flujos comunes que verás

• Authorization Code: típico en apps con usuario final (requiere navegador/redirect).
• Client Credentials: típico M2M (sin usuario), ideal para automatización.
• Resource Owner Password: cada vez menos recomendado; aún existe en sistemas legacy.
• Refresh Token: renovar access_token sin reautenticar al usuario.

Cómo usar OAuth 2.0 en Postman (práctico)

Postman puede obtener tokens desde la pestaña Authorization (Get New Access Token), pero para QA automatizado suele ser mejor capturarlos vía requests de login/token y scripts.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Ejemplo: Client Credentials (request de token)

Crea una request POST {{baseUrl}}/oauth/token (la ruta varía) con Content-Type: application/x-www-form-urlencoded y body tipo form:

• grant_type=client_credentials
• client_id={{client_id}}
• client_secret={{client_secret}}
• scope=read:orders write:orders (si aplica)

En Tests, captura el token:

const json = pm.response.json();pm.test('Token emitido', () => {  pm.expect(json).to.have.property('access_token');});pm.environment.set('access_token', json.access_token);if (json.refresh_token) {  pm.environment.set('refresh_token', json.refresh_token);}if (json.expires_in) {  const exp = Date.now() + (json.expires_in * 1000);  pm.environment.set('access_token_expires_at', String(exp));}

Validación de scopes/alcances

Si el servidor devuelve scope en la respuesta del token, valida que incluya lo esperado:

const json = pm.response.json();if (json.scope) {  pm.test('Scopes esperados presentes', () => {    pm.expect(json.scope).to.include('read:orders');  });}

Cookies y sesiones (cuando aplica)

Cuándo aparecen

En apps web tradicionales o APIs que usan sesión (por ejemplo, Set-Cookie con un session id). Postman puede almacenar cookies por dominio y reenviarlas automáticamente.

Guía práctica

1. Ejecuta el endpoint de login que responda con Set-Cookie.
2. Verifica en el Cookie Manager de Postman que la cookie se guardó para el dominio.
3. Ejecuta un endpoint protegido y confirma que la cookie se envía.

Checks de QA

• Cookie con flags de seguridad (si aplica): HttpOnly, Secure, SameSite.
• Expiración de sesión: tras TTL, debe pedir re-login.
• Invalidación: logout debe invalidar cookie/sesión.

Flujo completo de QA: login, captura de token y reutilización automática

Estructura sugerida de colección

• 00 - Auth
  • POST /login o POST /oauth/token (genera tokens)
  • POST /refresh (si existe)
• 10 - Recursos
  • Requests de negocio que heredan Bearer {{access_token}}

Paso a paso (token tipo JWT u opaco)

1. Crea la request de login/token y valida status 200.
2. En Tests, guarda access_token y opcionalmente expiración.
3. En la colección, configura Authorization Bearer con {{access_token}}.
4. Ejecuta una request protegida y agrega tests de autorización (200/403 según rol).

Pre-request script para renovar si expiró (opcional)

Si tu API ofrece refresh token, puedes chequear expiración antes de cada request. Nota: Postman no “pausa” automáticamente para ejecutar otra request desde un pre-request sin usar Collection Runner/Flows; una alternativa es ejecutar explícitamente la request de refresh antes del folder de recursos, o usar Postman Flows. Aun así, puedes implementar un guard simple para fallar rápido si está expirado:

const exp = Number(pm.environment.get('access_token_expires_at') || 0);if (exp && Date.now() > exp) {  throw new Error('access_token expirado: ejecuta el refresh/login antes de continuar');}

Casos de QA esenciales

1) Token expirado

Objetivo: asegurar que el backend rechaza tokens vencidos y que el cliente puede recuperarse (refresh o re-login).

• Ejecuta un token con TTL corto (si el entorno lo permite) o espera a que expire.
• Invoca un endpoint protegido.
• Valida respuesta: típicamente 401 y un código/mensaje de error consistente (por ejemplo, token_expired).

pm.test('Token expirado debe devolver 401', () => {  pm.expect(pm.response.code).to.equal(401);});

2) Permisos insuficientes (403)

Objetivo: confirmar que un usuario autenticado sin permisos no puede acceder.

• Obtén token de un usuario con rol limitado (por ejemplo, viewer).
• Ejecuta una operación restringida (por ejemplo, DELETE).
• Espera 403 y valida que no haya efectos colaterales.

pm.test('Sin permisos debe devolver 403', () => {  pm.expect(pm.response.code).to.equal(403);});

3) Rotación de credenciales (API keys, client secrets, passwords)

Objetivo: validar que el sistema soporta cambio de credenciales sin romper el flujo y que las credenciales antiguas se invalidan según política.

• Mantén dos variables: {{apiKey_active}} y {{apiKey_old}} (o client_secret_v1/client_secret_v2).
• Ejecuta requests con la credencial activa: debe pasar.
• Ejecuta con la antigua: debe fallar con 401/403 después del cutover.
• Registra en tests el comportamiento esperado por ventana de gracia (si existe).

4) Validación de claims/alcances (cuando estén disponibles)

Objetivo: verificar que el token emitido contiene lo necesario (scopes/roles/audiencia) y que el backend los hace cumplir.

Si el token es JWT, puedes inspeccionar su payload (sin verificar firma) para asserts básicos en QA. Ejemplo: decodificar la segunda parte Base64URL.

function base64UrlDecode(str) {  str = str.replace(/-/g, '+').replace(/_/g, '/');  const pad = str.length % 4;  if (pad) str += '='.repeat(4 - pad);  return atob(str);}const token = pm.environment.get('access_token');if (token && token.split('.').length === 3) {  const payload = JSON.parse(base64UrlDecode(token.split('.')[1]));  pm.test('JWT contiene exp', () => {    pm.expect(payload).to.have.property('exp');  });  if (payload.scope) {    pm.test('JWT incluye scope requerido', () => {      pm.expect(payload.scope).to.include('read:orders');    });  }}

Además de inspeccionar el token, valida autorización “de extremo a extremo”: un scope ausente debe reflejarse en un 403 al llamar al endpoint correspondiente.

Patrones de implementación para suites de QA en Postman

Separar identidades por entorno y por rol

• Variables por rol: viewer_user, admin_user (y sus passwords en Vault).
• Tokens por rol: access_token_viewer, access_token_admin si necesitas alternar en la misma ejecución.

Evitar duplicación de lógica

• Centraliza captura de token en una sola request de Auth.
• Usa herencia de Authorization a nivel colección.
• Usa scripts reutilizables (por ejemplo, en Collection-level pre-request/tests) para validaciones comunes.

Checks mínimos por request protegida

• 401 cuando falta token.
• 401 cuando token es inválido/expirado.
• 403 cuando token es válido pero sin permisos.
• 200/201/204 cuando token y permisos son correctos.