ブラウザ自動化におけるウェブ認証の取り扱い方法

TL;DR:

• ブラウザ自動化認証は、各ジョブのためにログインを繰り返すのではなく、承認されたセッションを再利用すべきです。 保存された状態は、クッキーとオリジンストレージを新しいブラウザコンテキストに持ち込みます。
• 認証は身元を証明し、認可はその身元が何を行えるかを決定します。 成功したサインインは、自動化の承認された範囲を拡大することはありません。
• セッションファイルは資格情報です。 ソース管理から取り除き、静止時に暗号化し、その寿命を制限し、アカウントと環境によって隔離します。
• MFA、パスキー、同意画面、デバイス承認は人間の境界を作ります。 それらのステップを承認されたオペレーターフローを通じて完了し、その後は結果として得られた承認されたセッションのみを再利用します。
• Scrapeless Scraping Browserは、承認されたブラウザセッションをクラウドブラウザに保持できます。 アプリケーションは引き続き資格情報の取り扱い、アカウントポリシー、アクセス決定を所有します。
• 無料で始められます。 新しいScrapelessアカウントには、無料のScraping Browserランタイムが含まれています — app.scrapeless.comでサインアップしてください。

Introduction: Authentication State Is a Security Boundary

ブラウザセッションは、サイトが身元の証明を受け入れ、その身元をブラウザの状態に結びつけると認証されます。その状態は、HttpOnlyクッキー、オリジンストレージ、メモリ内トークン、またはリダイレクト中に設定された複数の調整された値に存在する可能性があります。

自動化は、その状態をフォーム入力問題として扱うと失敗します。ログインを繰り返すことは、資格情報の露出を追加し、MFAのプロンプトを重複させ、期限切れのセッションとページの欠陥との違いを隠します。安全な設計は、承認された状態を一度作成し、その範囲を確認し、各ジョブにその状態だけをシードした新しいブラウザコンテキストを提供します。

このガイドは、Playwrightを使用してローカルテストアプリケーションで状態の境界を示した後、同じ承認されたワークフローがScrapeless Scraping Browserに接続する方法を示します。所有しているアカウントやシステム、または自動化を明示的に許可されたもののみで使用してください。

Authentication vs Authorization

認証は「このブラウザを使用しているのはどの身元か？」に答えます。認可は「その身元がどのリソースやアクションにアクセスできるか？」に答えます。ブラウザ自動化には両方のチェックが必要です。

OAuthは認可フレームワークですが、そのリダイレクトはサインインの旅の中にしばしば表示されます。 OAuth 2.0は役割と認可グラントフローを定義します; ブラウザは認可コードやアクセストークンをログに露出してはいけません。

How Browser Sessions Persist Identity

クッキーは最も一般的なブラウザ側のセッションキャリアです。サーバーはクッキーを発行し、ブラウザはそのドメイン、パス、期限、セキュリティ属性を適用し、その後、スコープが一致したときにリクエストに含めます。 HTTP状態管理仕様はクッキーストレージと一致を定義します。

アプリケーションはまた、localStorageやIndexedDBにトークンやアカウントヒントを保存することがあります。sessionStorageは異なります: それは1つのトップレベルのブラウジングコンテキストに属し、通常のストレージ状態のエクスポートによって自動的に再現されることはありません。再利用を設計する前に、実際の状態表面を特定してください。

JWTはトークンフォーマットを説明するものであり、ブラウザセッション戦略ではありません。JWTはクッキー、オリジンストレージ、またはアプリケーションメモリ内のみに表示される場合があります。含まれるメカニズムをセキュリティ境界とみなしてください。

Passwords, Sessions, OAuth, and WebAuthn

各認証方法は異なる自動化の境界を作成します。

テストハーネスをインストールする

実行される例はNode.jsとPlaywrightを使用しています。検証実行に使用するのと同じパッケージバージョンをインストールしてください。

npm install playwright@1.62.1

状態ファイル用に専用の.authディレクトリを使用し、それをバージョン管理から除外します。状態ファイルは、テストアカウントを模倣するのに十分かもしれません。

認可されたセッションを安全に再利用する

以下のスクリプトは、偽のテストアカウントを持つローカルアプリケーションを作成し、1回サインインし、ブラウザ状態を保存し、新しいコンテキストから保護されたルートを開きます。サードパーティのログインサービスに連絡したり、実際の認証情報を使用したりすることはありません。

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

ライブ実行はHTTP 200、タイトルAuthorized account、およびdemo_sessionという名前のクッキーを返しました。これは、復元されたコンテキストがログインを繰り返すことなく承認された状態を受け取ったことを証明します。

Scrapelessでスクレイピングを開始する

Scrapelessでウェブスクレイピングと自動化ワークフローをパワーアップしましょう！
今日サインアップして5ドルの無料クレジットをゲット — クレジットカードは不要。

今すぐScrapelessダッシュボードで無料クレジットを取得してください。

MFAとパスキーの境界

MFAは承認された人またはデバイスが存在することを証明します。自動化はその証明を弱めるべきではありません。

所有するテストシステムに対しては、アイデンティティプロバイダーのテストテナント、専用アカウント、ドキュメント化された仮想認証器を使用してください。プロダクションアクセスの場合、オペレーターは通常のインターフェースを通じてMFA、パスキー、同意、またはデバイス承認ステップを完了させる必要があります。それ以降は、ポリシーで定義された期限まで発行されたセッションを再利用できます。

人のワンタイムコードを収集したり、デバイスにバウンドされたパスキーをコピーしたり、同意画面を抑制したりしないでください。 OWASPセッション管理ガイダンスは、セッション識別子に同じ注意が必要である理由を説明しています。

Scrapeless Scraping Browserでフローを実装する

Scrapeless Scraping Browserはブラウザプロセスを管理されたクラウドブラウザに移動させますが、あなたのPlaywrightコードはナビゲーションと状態の制御を維持します。

Playwrightの横にSDKをインストールしてください：

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

注意：次のブロックでは、Scrapeless APIキーと自動化することが認可されているアカウントが必要です。認証情報のない検証環境は正確なSDKを読み込み、Playwright.connectが関数であることを確認しましたが、認証されたクラウドセッションを作成することはできませんでした。

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

Scrapeless Scraping BrowserドキュメントではAPIキーのセットアップとセッションの作成について説明しています。Scraping Browser製品ページと料金ページでは、管理されたブラウザサーフェスについて説明しています。

認証状態をデバッグする

外部から内部へのアイデンティティ状態をデバッグします。最終URLと表示されるアカウントマーカーから始めて、その状態をサポートするはずのブラウザストレージを確認してください。

セキュリティとコンプライアンスのチェックリスト

• ワークフローがアクセスを許可されたシステム、テナント、およびアカウントのみを使用します。
• 自動化アカウントには、承認されたタスクを完了できる最小限の役割を付与します。
• パスワードとキーは実行時に供給し、ソースやスクリーンショットには決して配置しないでください。
• クッキー、ストレージ状態ファイル、認証コード、およびトークンは秘密として扱います。
• セッションアーティファクトを暗号化し、ファイル権限を制限し、ポリシーの期限が切れたら削除します。
• 開発、ステージング、および本番環境のアイデンティティを分離します。
• MFA、同意、財務行動、特権変更、および破壊的操作には人間の承認を必要とします。
• 秘密値を記録せずに、目的、アカウントエイリアス、ターゲットオリジン、および結果を記録します。

結論: 認証情報ではなく証明を再利用する

信頼できるブラウザ自動化は、狭い承認されたセッションを作成し、それを検証し、孤立したコンテキストでその証明を再利用します。成功した認証をあらゆる行動の許可として扱うことはありません。

セッションアーティファクトを短命にし、保護された状態に保ちます。人々が設計されたセキュリティセレモニーを完了できるようにします。承認されたワークフローが管理されたブラウザセッションを必要とする場合には、Scrapeless Scraping Browserを使用し、認証の境界をクラウドプロバイダーに移動しないようにします。

承認されたブラウザワークフローを構築する準備はできましたか？

私たちのコミュニティに参加して、無料プランを取得し、制御されたブラウザ自動化を構築している開発者とつながりましょう: Discord · Telegram。

app.scrapeless.com にサインアップして、無料のScraping Browserランタイムを取得し、自動化を許可されたアカウントに状態分離パターンを適用します。

FAQ

Q: 認証されたウェブサイトを自動化することは合法ですか？

承認された自動化は合法である可能性がありますが、その答えは法域、契約、データ、および行動によって異なります。所有または明示的に承認されたアカウントを使用し、サイトの利用規約とプライバシー規則を確認し、特定のワークフローについて法律顧問に相談してください。

Q: ブラウザ自動化はパスワードまたはセッションを保存するべきですか？

ブラウザ自動化は通常、実行時に秘密を受け取り、短命の承認されたセッションを作成し、保護された状態を再利用すべきです。保存されたセッションは認証情報として扱われ、暗号化、アクセス制御、期限切れ、および削除が必要です。

Q: 自動化はMFAまたはパスキーを扱えますか？

自動化は所有されたテスト環境でテスト認証機を使用できますが、生産環境のMFA、パスキー、同意、またはデバイス承認ステップは承認されたオペレーターに残すべきです。結果のセッションはその承認された範囲内でのみ再利用します。

Q: 認証されたワークフローにはプロキシが必要ですか？

認証されたワークフローは、アプリケーションがリスクポリシーまたはコンテンツを場所にバインドする場合に、安定した地域的な出口を必要とすることがあります。セッションの承認された国を固定し、1つのアイデンティティフロー内で地域を変更しないでください。

Q: マークアップが変更された場合、何が起こるべきですか？

役割に基づくロケーターとポストログインのアサーションを再確認してください。認証状態とDOMセレクタは別の懸念事項です。妥当なセッションは変更されたインターフェースと共存することができます。

Q: 認証されたアカウントはどれくらいの同時実行を使用すべきですか？

アプリケーションの所有者が別の制限を承認しない限り、ホストごとに3人のワーカーを超えないようにし、並列ジョブが共有サーバー側の状態を変更できる場合は、別のアカウントを使用してください。

Q: これはAIエージェントなしで実行できますか？

はい。PlaywrightとScrapeless SDKは、承認されたフロー全体を直接実行できます。AIエージェントはオプションであり、同じアカウント、アクション、および承認の境界内で操作する必要があります。