POST de login en DevTools: payload, cookies y autenticación real
Análisis del POST de login en Chrome DevTools: cómo se envían las credenciales al backend, qué payload usa y qué cookie de autenticación devuelve el servidor.
En el paso anterior, el análisis cubrió el GET de la página de login. El navegador pedía el HTML de la pantalla y el servidor devolvía una cookie CSRF-TOKEN.
Ese request no procesaba credenciales. Solo cargaba la página.
El siguiente paso cambia de nivel:
POST /Account/Login
Acá ya no se pide una página. Acá se intenta autenticar.
La request en Network
La request que aparece en Network después de hacer click en "Iniciar sesión" es esta:
| Campo | Valor |
|---|---|
| Request URL | https://demo.serenity.is/Account/Login |
| Request Method | POST |
| Status Code | 200 OK |
Solo con esas tres líneas ya cambia bastante el panorama.
Ya no es una carga de página
En el paso 1 el método era GET. Ahora es POST.
La diferencia, traducida a lo esencial:
- GET se usa para pedir algo
- POST se usa para enviar algo al servidor para que lo procese
Encaja perfecto con lo que pasa acá: el navegador ya no pide la pantalla de login, ahora le manda las credenciales al backend.
El endpoint es más simple
En el paso 1 la URL era /Account/Login/?ReturnUrl=%2F. Ahora es simplemente /Account/Login.
El ReturnUrl desaparece del path principal porque ya no se está pidiendo la pantalla. Ahora se está ejecutando la acción de login.
Lo más importante del paso 2: el Payload
En la pestaña Payload aparece esto:
{
"Username": "admin",
"Password": "serenity"
}
Esta es una de las partes más útiles de todo el ejercicio.
Porque una cosa es saber que la app se loguea con admin / serenity, y otra muy distinta es ver exactamente cómo envía esos datos al backend.
Qué revela este payload
1. El login manda JSON
No está enviando un form clásico tipo application/x-www-form-urlencoded. Está mandando un payload estructurado con claves y valores.
2. Los nombres exactos de los campos importan
No es "usuario" o "password" en abstracto. Es exactamente Username y Password, con mayúsculas como aparecen ahí.
En API testing no alcanza con "la idea general". El backend espera nombres concretos.
3. El login ya es una API de verdad
Aunque viene desde una app web, esto se comporta como una llamada de API clara: URL, método, payload JSON, response, cookies. El formulario visual de login es solo la superficie. Debajo hay un request técnico perfectamente identificable.
Lo que devolvió el servidor
En Response no aparece un cuerpo útil porque DevTools muestra:
Failed to load response data
Eso puede pasar y no invalida el análisis. Lo importante acá no es el body, sino lo que queda visible en Headers y Cookies.
Y ahí aparece la pieza más relevante.
La cookie que nace con el login
En la pestaña Cookies del request POST /Account/Login:
Request Cookies:
- Cookie anti-forgery
- CSRF-TOKEN
Response Cookies:
- AspNetAuth
Ese dato es clave.
Qué significa
El login no solo valida usuario y contraseña. Si la autenticación es exitosa, el servidor devuelve una cookie nueva: AspNetAuth.
Esa cookie cambia el estado del navegador:
- Antes del login: había contexto de página, había CSRF-TOKEN, pero no había sesión autenticada.
- Después del login: aparece
AspNetAuth, y a partir de ese momento el navegador está autenticado para requests futuros.
El flujo completo hasta acá
| Paso | Request | Acción | Cookie relevante |
|---|---|---|---|
| 1 | GET /Account/Login/?ReturnUrl=%2F |
Carga HTML | Devuelve CSRF-TOKEN |
| 2 | POST /Account/Login |
Envía Username y Password | Devuelve AspNetAuth |
Este encadenamiento es lo que hay que entender antes de abrir Postman: el endpoint protegido de la app no vive aislado. Antes hay un flujo de autenticación que establece cookies y contexto.
Por qué esto cambia la forma de ver la app
Sin este análisis, el login parece "un formulario". Con este análisis, se ve como una secuencia técnica clara:
- El navegador carga la página de login
- El servidor devuelve cookies iniciales
- El navegador manda un POST con credenciales
- El servidor devuelve cookie de autenticación
- Recién después tiene sentido pedir endpoints protegidos
Cuando se ve así, Postman deja de ser una herramienta para "pegarle a URLs" y pasa a ser una herramienta para reproducir flujos reales.
Resumen del Paso 2
El request de login muestra el momento exacto donde la aplicación deja de mostrar una pantalla y pasa a procesar autenticación real.
Con DevTools se puede ver:
- El login real es un POST — La autenticación no ocurre al cargar la página, sino al enviar credenciales al backend.
- El payload importa — El request manda JSON con claves exactas:
UsernameyPassword. - La autenticación deja huella en cookies — Después del login aparece
AspNetAuth. - Los endpoints protegidos dependen de este flujo — No son requests aislados. Se apoyan en una sesión autenticada.
Qué sigue
Después del login, la aplicación ya está autenticada. El siguiente paso lógico es analizar el request que alimenta la grilla de clientes.
Ahí ya no va a haber HTML ni credenciales. Va a ser un endpoint de datos, con payload propio, response JSON y volumen real de información.
Y ahí es donde API testing muestra una ventaja concreta sobre la UI: validar datos de la grilla sin depender de scroll, renderizado ni sincronización visual.