Cómo manejar la autenticación web en la automatización del navegador

TL;DR:

• La autenticación de automatización del navegador debe reutilizar una sesión aprobada en lugar de repetir un inicio de sesión para cada trabajo. Un estado guardado puede llevar cookies y almacenamiento de origen a un nuevo contexto del navegador.
• La autenticación prueba la identidad; la autorización decide lo que esa identidad puede hacer. Un inicio de sesión exitoso nunca expande el alcance aprobado de la automatización.
• Los archivos de sesión son credenciales. Mantenlos fuera del control de versiones, encríptalos en reposo, limita su duración y aísla por cuenta y entorno.
• MFA, claves de paso, pantallas de consentimiento y aprobación de dispositivos crean límites humanos. Completa esos pasos a través de un flujo de operador aprobado, y luego reutiliza solo la sesión autorizada resultante.
• Scraping Browser sin chatarra puede mantener la sesión del navegador autorizado en un navegador en la nube. Tu aplicación todavía es responsable del manejo de credenciales, políticas de cuenta y decisiones de acceso.
• Libre para comenzar. Nuevas cuentas de Scrapeless incluyen tiempo de ejecución gratuito de Scraping Browser — regístrate en app.scrapeless.com.

Introducción: El estado de autenticación es una frontera de seguridad

Una sesión de navegador se convierte en autenticada cuando un sitio acepta prueba de identidad y vincula esa identidad al estado del navegador. Ese estado puede residir en una cookie HttpOnly, almacenamiento de origen, un token en memoria, o varios valores coordinados establecidos durante redirecciones.

La automatización falla cuando trata ese estado como un problema de llenado de formularios. Repetir un inicio de sesión añade exposición de credenciales, duplica los mensajes de MFA, y oculta la diferencia entre una sesión expirada y un defecto de página. Un diseño más seguro crea un estado autorizado una vez, verifica su alcance y le da a cada trabajo un nuevo contexto del navegador sembrado solo con ese estado.

Esta guía usa Playwright para demostrar la frontera del estado en una aplicación de prueba local, luego muestra cómo el mismo flujo de trabajo autorizado se conecta a Scrapeless Scraping Browser. Úsalo solo con cuentas y sistemas que poseas o que estés explícitamente autorizado a automatizar.

Autenticación vs Autorización

La autenticación responde “¿Qué identidad está usando este navegador?” La autorización responde “¿A qué recursos y acciones puede acceder esa identidad?” La automatización del navegador necesita ambas comprobaciones.

OAuth es un marco de autorización, aunque sus redirecciones a menudo aparecen dentro de un viaje de inicio de sesión. OAuth 2.0 define los roles y el flujo de concesión de autorización; el navegador no debería exponer códigos de autorización ni tokens de acceso a los registros.

Cómo las sesiones del navegador persisten la identidad

Las cookies siguen siendo el portador más común de sesiones del lado del navegador. El servidor emite una cookie, el navegador aplica su dominio, ruta, expiración y atributos de seguridad, y las solicitudes posteriores la incluyen cuando el alcance coincide. la especificación de gestión de estado HTTP define el almacenamiento y coincidencia de cookies.

Las aplicaciones también pueden almacenar tokens o pistas de cuentas en localStorage o IndexedDB. sessionStorage es diferente: pertenece a un contexto de navegación de nivel superior y no se reproduce automáticamente mediante una exportación de estado de almacenamiento normal. Identifica la superficie de estado real antes de diseñar la reutilización.

JWT describe un formato de token, no una estrategia de sesión de navegador. Un JWT puede aparecer en una cookie, en almacenamiento de origen, o solo en la memoria de la aplicación. Trata el mecanismo contenedor como la frontera de seguridad.

Contraseñas, Sesiones, OAuth y WebAuthn

Cada método de autenticación crea un límite de automatización diferente.

Instalar el Marco de Pruebas

El ejemplo ejecutado utiliza Node.js y Playwright. Instala la misma versión del paquete utilizada para la ejecución de verificación:

npm install playwright@1.62.1

Utiliza un .auth dedicado para los archivos de estado y exclúyelo del control de versiones. El archivo de estado puede ser suficiente para suplantar la cuenta de prueba mientras permanezca válida.

Reutilizar una Sesión Autorizada de Manera Segura

El siguiente script crea una aplicación local con una cuenta de prueba falsa, inicia sesión una vez, guarda el estado del navegador y abre la ruta protegida desde un nuevo contexto. No contacta a un servicio de inicio de sesión de terceros ni utiliza credenciales reales.

import http from "node:http";
import fs from "node:fs/promises";
import { chromium } from "playwright";

const server = http.createServer(async (request, response) => {
  const url = new URL(request.url, "http://127.0.0.1");
  const cookies = request.headers.cookie ?? "";

  if (request.method === "POST" && url.pathname === "/login") {
    let body = "";
    for await (const chunk of request) body += chunk;
    const form = new URLSearchParams(body);
    if (form.get("username") === "test-user" && form.get("password") === "test-password") {
      response.writeHead(302, {
        "Set-Cookie": "demo_session=authorized; HttpOnly; SameSite=Lax; Path=/",
        Location: "/account",
      });
      response.end();
      return;
    }
  }

  if (url.pathname === "/account") {
    const authorized = cookies.includes("demo_session=authorized");
    response.writeHead(authorized ? 200 : 401, { "Content-Type": "text/html" });
    response.end(`<title>${authorized ? "Authorized account" : "Sign in required"}</title>`);
    return;
  }

  response.writeHead(200, { "Content-Type": "text/html" });
  response.end(`<form method="post" action="/login">
    <label>Username <input name="username"></label>
    <label>Password <input name="password" type="password"></label>
    <button>Sign in</button>
  </form>`);
});

await new Promise(resolve => server.listen(0, "127.0.0.1", resolve));
const address = server.address();
const baseUrl = `http://127.0.0.1:${address.port}`;
const statePath = "authorized-state.json";
const browser = await chromium.launch({
  headless: true,
  executablePath: process.env.CHROME_PATH || undefined,
});

try {
  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto(baseUrl);
  await page.getByLabel("Username").fill("test-user");
  await page.getByLabel("Password").fill("test-password");
  await Promise.all([
    page.waitForURL(`${baseUrl}/account`),
    page.getByRole("button", { name: "Sign in" }).click(),
  ]);
  await context.storageState({ path: statePath });
  await context.close();

  const restored = await browser.newContext({ storageState: statePath });
  const restoredPage = await restored.newPage();
  const result = await restoredPage.goto(`${baseUrl}/account`);
  const state = JSON.parse(await fs.readFile(statePath, "utf8"));
  console.log(JSON.stringify({
    status: result.status(),
    title: await restoredPage.title(),
    cookieNames: state.cookies.map(cookie => cookie.name),
  }));
  await restored.close();
} finally {
  await browser.close();
  server.close();
  await fs.rm(statePath, { force: true });
}

La ejecución en vivo devolvió HTTP 200, el título Authorized account y una cookie llamada demo_session. Eso prueba que el contexto restaurado recibió el estado autorizado sin repetir el inicio de sesión.

Comienza a Hacer Scraping con Scrapeless

¡Potencia tu scraping web y flujo de trabajo de automatización con Scrapeless!
Regístrate hoy y obtén $5 en crédito gratis — no se requiere tarjeta de crédito.

Reclama tu crédito gratis ahora en el Tablero de Scrapeless.

Límites de MFA y Claves de Paso

MFA demuestra que una persona o dispositivo aprobado está presente. La automatización no debería debilitar esa prueba.

Para un sistema de prueba propio, utiliza inquilinos de prueba de proveedor de identidad, cuentas dedicadas y autenticadores virtuales documentados. Para acceso a producción, deja que el operador complete el MFA, la clave de paso, el consentimiento o el paso de aprobación del dispositivo a través de la interfaz normal. El flujo de trabajo puede reutilizar la sesión emitida hasta su expiración definida por la política.

No recojas códigos de un solo uso de una persona, no copies una clave de paso vinculada al dispositivo, ni suprimas una pantalla de consentimiento. La guía de gestión de sesión de OWASP explica por qué los identificadores de sesión requieren el mismo cuidado que las credenciales de autenticación.

Implementar el Flujo con Scrapeless Scraping Browser

Scrapeless Scraping Browser mueve el proceso del navegador a un navegador en la nube gestionado mientras tu código de Playwright mantiene el control de la navegación y el estado.

Instala el SDK junto a Playwright:

npm install @scrapeless-ai/sdk@1.11.0 playwright@1.62.1

Nota: El siguiente bloque requiere tu clave API de Scrapeless y una cuenta que estás autorizado a automatizar. El entorno de verificación sin credenciales cargó el SDK exacto y confirmó que Playwright.connect es una función, pero no pudo crear la sesión en la nube autenticada.

import { Playwright } from "@scrapeless-ai/sdk";

const browser = await Playwright.connect({
  sessionName: "authorized-workflow",
  sessionTTL: 300,
  proxyCountry: "US",
});

const context = browser.contexts()[0];
const page = await context.newPage();
await page.goto("https://app.example.com/login", { waitUntil: "domcontentloaded" });

// Complete only the login steps approved for this account.
// An operator handles any MFA, passkey, consent, or device-approval boundary.

await page.waitForURL("https://app.example.com/account");
const state = await context.storageState();
console.log(JSON.stringify({ cookieCount: state.cookies.length, originCount: state.origins.length }));
await browser.close();

La documentación de Scrapeless Scraping Browser cubre la configuración de la clave API y la creación de sesiones. La página del producto Scraping Browser y precios describen la superficie del navegador gestionado.

Depurar el Estado de Autenticación

Depura el estado de identidad desde afuera hacia adentro. Comienza con la URL final y el marcador de cuenta visible, luego inspecciona el almacenamiento del navegador que debería respaldar ese estado.

Lista de Verificación de Seguridad y Cumplimiento

• Utilice solo sistemas, inquilinos y cuentas a los que el flujo de trabajo esté autorizado a acceder.
• Asigne a la cuenta de automatización el rol más pequeño que pueda completar la tarea aprobada.
• Proporcione contraseñas y claves en tiempo de ejecución; nunca las coloque en el código fuente o capturas de pantalla.
• Trate las cookies, archivos de estado de almacenamiento, códigos de autorización y tokens como secretos.
• Cifre los artefactos de la sesión, restrinja los permisos de archivo y elimínelos al expirar la política.
• Separe identidades de desarrollo, prueba y producción.
• Requiere aprobación humana para MFA, consentimiento, acciones financieras, cambios de privilegios y operaciones destructivas.
• Registre el propósito, alias de cuenta, origen objetivo y resultado sin registrar valores secretos.

Conclusión: Reutilizar Prueba, No Credenciales

La automatización de navegadores fiable crea una sesión autorizada estrecha, la verifica y reutiliza esa prueba en contextos aislados. No repite credenciales en cada página ni trata la autenticación exitosa como permiso para cada acción.

Mantenga los artefactos de la sesión de corta duración y protegidos. Permita que las personas completen ceremonias de seguridad diseñadas para personas. Utilice Scrapeless Scraping Browser cuando el flujo de trabajo aprobado necesite una sesión de navegador gestionada sin mover la frontera de autorización al proveedor de la nube.

¿Listo para Construir un Flujo de Trabajo de Navegador Autorizado?

Únase a nuestra comunidad para reclamar un plan gratuito y conectarse con desarrolladores que construyen automatización de navegadores controlados: Discord · Telegram.

Regístrese en app.scrapeless.com para obtener runtime de Scraping Browser gratuito y aplique el patrón de aislamiento de estado a una cuenta que esté autorizado a automatizar.

FAQ

Q: ¿Es legal automatizar un sitio web autenticado?

La automatización autorizada puede ser legal, pero la respuesta depende de la jurisdicción, contrato, datos y acción. Utilice una cuenta propia o explícitamente aprobada, revise los términos y reglas de privacidad del sitio, y consulte con un abogado para el flujo de trabajo específico.

Q: ¿Debería la automatización del navegador almacenar una contraseña o una sesión?

La automatización del navegador normalmente debería recibir secretos en tiempo de ejecución, crear una sesión autorizada de corta duración y reutilizar el estado protegido. Una sesión almacenada sigue siendo una credencial y necesita cifrado, control de acceso, caducidad y eliminación.

Q: ¿Puede la automatización manejar MFA o una clave de acceso?

La automatización puede utilizar autenticadores de prueba en un entorno de prueba propio, pero un MFA de producción, clave de acceso, consentimiento o paso de aprobación de dispositivo debe permanecer con el operador autorizado. Reutilice la sesión resultante solo dentro de su ámbito aprobado.

Q: ¿Necesitan los flujos de trabajo autenticados un proxy?

Los flujos de trabajo autenticados pueden necesitar egress regional estable cuando la aplicación vincula política de riesgo o contenido a la ubicación. Fije el país aprobado para la sesión y no cambie regiones dentro de un flujo de identidad.

Q: ¿Qué debería suceder cuando cambia el marcado?

Verifique nuevamente los localizadores basados en roles y la afirmación posterior a la autenticación. El estado de autenticación y los selectores DOM son preocupaciones separadas; una sesión válida puede coexistir con una interfaz cambiada.

Q: ¿Cuánta concurrencia debería utilizar una cuenta autenticada?

No mantenga más de tres trabajadores por anfitrión a menos que el propietario de la aplicación apruebe otro límite, y use cuentas separadas cuando trabajos paralelos puedan cambiar el estado compartido del servidor.

Q: ¿Puede esto funcionar sin un agente de IA?

Sí. Playwright y el SDK de Scrapeless pueden ejecutar todo el flujo autorizado directamente. Un agente de IA es opcional y debe operar dentro de los mismos límites de cuenta, acción y aprobación.