Como Lidar com Autenticação Web em Automação de Navegador

TL;DR:

• A autenticação de automação do navegador deve reutilizar uma sessão aprovada em vez de repetir um login para cada trabalho. Um estado salvo pode carregar cookies e armazenamento de origem em um novo contexto do navegador.
• A autenticação prova identidade; a autorização decide o que essa identidade pode fazer. Um login bem-sucedido nunca expande o escopo aprovado da automação.
• Os arquivos de sessão são credenciais. Mantenha-os fora do controle de versão, criptografe-os em repouso, limite sua vida útil e isole-os por conta e ambiente.
• MFA, chaves de acesso, telas de consentimento e aprovação de dispositivos criam limites humanos. Complete essas etapas através de um fluxo de operador aprovado e reutilize apenas a sessão autorizada resultante.
• O Scrapeless Scraping Browser pode manter a sessão do navegador autorizada em um navegador na nuvem. Sua aplicação ainda possui o manuseio de credenciais, políticas de conta e decisões de acesso.
• Livre para começar. Novas contas Scrapeless incluem execução gratuita do Scraping Browser — inscreva-se em app.scrapeless.com.

Introdução: O Estado de Autenticação é uma Fronteira de Segurança

Uma sessão de navegador se torna autenticada quando um site aceita prova de identidade e vincula essa identidade ao estado do navegador. Esse estado pode viver em um HttpOnly cookie, armazenamento de origem, um token em memória ou vários valores coordenados definidos durante redirecionamentos.

A automação falha quando trata esse estado como um problema de preenchimento de formulário. Repetir um login aumenta a exposição de credenciais, duplica os prompts de MFA e oculta a diferença entre uma sessão expirada e um defeito na página. Um design mais seguro cria um estado autorizado uma vez, verifica seu escopo e dá a cada trabalho um contexto de navegador fresco preenchido apenas com esse estado.

Este guia utiliza Playwright para demonstrar a fronteira de estado em um aplicativo de teste local, e depois mostra como o mesmo fluxo autorizado se conecta ao Scrapeless Scraping Browser. Use-o apenas com contas e sistemas que você possui ou que está explicitamente autorizado a automatizar.

Autenticação vs Autorização

A autenticação responde “Qual identidade está usando este navegador?” A autorização responde “Quais recursos e ações essa identidade pode acessar?” A automação do navegador precisa de ambas as verificações.

OAuth é um framework de autorização, mesmo que seus redirecionamentos muitas vezes apareçam durante uma jornada de login. OAuth 2.0 define os papéis e o fluxo de concessão de autorização; o navegador não deve expor códigos de autorização ou tokens de acesso para os logs.

Como as Sessões do Navegador Persistem a Identidade

Cookies permanecem como o transportador de sessão comum do lado do navegador. O servidor emite um cookie, o navegador aplica seu domínio, caminho, expiração e atributos de segurança, e as solicitações posteriores o incluem quando o escopo corresponde. a especificação de gerenciamento de estado HTTP define armazenamento e correspondência de cookies.

As aplicações também podem armazenar tokens ou dicas de conta em localStorage ou IndexedDB. sessionStorage é diferente: pertence a um único contexto de navegação de nível superior e não é reproduzido automaticamente por uma exportação de estado de armazenamento normal. Identifique a verdadeira superfície de estado antes de projetar a reutilização.

JWT descreve um formato de token, não uma estratégia de sessão do navegador. Um JWT pode aparecer em um cookie, em armazenamento de origem ou apenas na memória da aplicação. Trate o mecanismo que contém como a fronteira de segurança.

Senhas, Sessões, OAuth e WebAuthn

Cada método de autenticação cria uma fronteira de automação diferente.

Instalar o Test Harness

O exemplo executado utiliza Node.js e Playwright. Instale a mesma versão do pacote usada para a execução de verificação:

npm install playwright@1.62.1

Use um diretório dedicado .auth para arquivos de estado e exclua-o do controle de versão. O arquivo de estado pode ser suficiente para personificar a conta de teste enquanto ela permanecer válida.

Reutilizar uma Sessão Autorizada com Segurança

O seguinte script cria uma aplicação local com uma conta de teste falsa, faz login uma vez, salva o estado do navegador e abre a rota protegida de um novo contexto. Ele não entra em contato com um serviço de login de terceiros ou usa credenciais reais.

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 });
}

A execução ao vivo retornou HTTP 200, o título Authorized account e um cookie nomeado demo_session. Isso prova que o contexto restaurado recebeu o estado autorizado sem repetir o login.

Comece a Raspagem com Scrapeless

Potencialize sua raspagem na web e fluxo de automação com Scrapeless!
Inscreva-se hoje e receba $5 em crédito gratuito — sem necessidade de cartão de crédito.

Reivindique seu crédito gratuito agora no Painel do Scrapeless.

Limites de MFA e Chave de Acesso

A MFA prova que uma pessoa ou dispositivo aprovado está presente. A automação não deve enfraquecer essa prova.

Para um sistema de teste de propriedade, use locatários de teste do provedor de identidade, contas dedicadas e autenticadores virtuais documentados. Para acesso de produção, deixe o operador completar a MFA, chave de acesso, consentimento ou etapa de aprovação de dispositivo através da interface normal. O fluxo de trabalho pode então reutilizar a sessão emitida até seu prazo de expiração definido pela política.

Não colete os códigos de uso único de uma pessoa, copie uma chave de acesso vinculada a um dispositivo ou oculte uma tela de consentimento. A orientação de gerenciamento de sessão da OWASP explica por que os identificadores de sessão requerem o mesmo cuidado que as credenciais de autenticação.

Implemente o Fluxo com o Navegador de Raspagem Scrapeless

O Navegador de Raspagem Scrapeless move o processo do navegador para um navegador na nuvem gerenciado, enquanto seu código Playwright mantém o controle da navegação e do estado.

Instale o SDK ao lado do Playwright:

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

Observação: O bloco a seguir requer sua chave de API Scrapeless e uma conta que você está autorizado a automatizar. O ambiente de verificação sem credenciais carregou o SDK exato e confirmou que Playwright.connect é uma função, mas não conseguiu criar a sessão na nuvem 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();

A documentação do Navegador de Raspagem Scrapeless cobre a configuração da chave da API e a criação de sessão. A página do produto do Navegador de Raspagem e preços descrevem a superfície do navegador gerenciado.

Depurar o Estado de Autenticação

Depure o estado de identidade de fora para dentro. Comece com a URL final e o marcador de conta visível, depois inspecione o armazenamento do navegador que deve suportar esse estado.

Lista de Verificação de Segurança e Conformidade

• Use apenas sistemas, locatários e contas que o fluxo de trabalho está autorizado a acessar.
• Dê à conta de automação o menor papel que possa concluir a tarefa aprovada.
• Forneça senhas e chaves em tempo de execução; nunca as coloque no código-fonte ou em capturas de tela.
• Trate cookies, arquivos de estado de armazenamento, códigos de autorização e tokens como segredos.
• Criptografe artefatos de sessão, restrinja permissões de arquivo e delete-os na expiração da política.
• Separe identidades de desenvolvimento, teste e produção.
• Exija aprovação humana para MFA, consentimento, ações financeiras, mudanças de privilégio e operações destrutivas.
• Registre o propósito, o alias da conta, a origem do alvo e o resultado sem registrar valores secretos.

Conclusão: Reutilize a Prova, Não Credenciais

A automação de navegador confiável cria uma sessão autorizada estreita, verifica-a e reutiliza essa prova em contextos isolados. Ela não repete credenciais em cada página ou trata a autenticação bem-sucedida como permissão para cada ação.

Mantenha os artefatos de sessão de curta duração e protegidos. Deixe que as pessoas completem cerimônias de segurança projetadas para elas. Use o Scrapeless Scraping Browser quando o fluxo de trabalho aprovado precisar de uma sessão de navegador gerenciada sem mover o limite de autorização para o provedor de nuvem.

Pronto para Criar um Fluxo de Trabalho de Navegador Autorizado?

Junte-se à nossa comunidade para obter um plano gratuito e se conectar com desenvolvedores que estão criando automação de navegador controlada: Discord · Telegram.

Inscreva-se em app.scrapeless.com para obter o runtime gratuito do Scraping Browser e aplique o padrão de isolamento de estado a uma conta que você está autorizado a automatizar.

FAQ

Q: É legal automatizar um site autenticado?

A automação autorizada pode ser legal, mas a resposta depende da jurisdição, contrato, dados e ação. Use uma conta possuída ou explicitamente aprovada, revise os termos e regras de privacidade do site, e consulte um advogado para o fluxo de trabalho específico.

Q: A automação de navegador deve armazenar uma senha ou uma sessão?

A automação de navegador deve normalmente receber segredos em tempo de execução, criar uma sessão autorizada de curta duração e reutilizar o estado protegido. Uma sessão armazenada permanece uma credencial e precisa de criptografia, controle de acesso, expiração e exclusão.

Q: A automação pode lidar com MFA ou uma chave de acesso?

A automação pode usar autenticadores de teste em um ambiente de teste possuído, mas um passo de MFA de produção, chave de acesso, consentimento ou aprovação de dispositivo deve permanecer com o operador autorizado. Reuse a sessão resultante apenas dentro de seu escopo aprovado.

Q: Fluxos de trabalho autenticados precisam de um proxy?

Fluxos de trabalho autenticados podem precisar de um egress regional estável quando a aplicação vincula a política de risco ou conteúdo à localização. Defina o país aprovado para a sessão e não altere regiões dentro de um fluxo de identidade.

Q: O que deve acontecer quando a marcação muda?

Verifique novamente os localizadores baseados em funções e a asserção pós-login. O estado de autenticação e os seletores DOM são preocupações separadas; uma sessão válida pode coexistir com uma interface alterada.

Q: Quanta concorrência uma conta autenticada deve usar?

Mantenha não mais do que três trabalhadores por host, a menos que o proprietário da aplicação aprove outro limite, e use contas separadas quando trabalhos paralelos puderem alterar o estado compartilhado do servidor.

Q: Isso pode ser executado sem um agente de IA?

Sim. O Playwright e o SDK do Scrapeless podem executar todo o fluxo autorizado diretamente. Um agente de IA é opcional e deve operar sob os mesmos limites de conta, ação e aprovação.