1Password Autologin: Sign In to Authenticated Sites Without Exposing a Password

TL;DR

  • Autologin is a new way to create an Authenticated Profile: connect a 1Password service account, and a hosted agent signs in for you.
  • Your code sends a vault reference, not a secret. Browserless resolves it server-side and types it into the field inside the session.
  • The finished sign-in is saved as a normal, reusable profile you can attach to any supported session with ?profile=<name>.
  • Nobody has to approve the sign-in by hand, and every credential use is written to an audit log.

Log in once, and let 1Password do the typing

With Authenticated Profiles, you can capture a logged-in browser's auth state once, then reuse it across many parallel sessions. When we launched Authenticated Profiles, someone had to script the first login, or hand the browser to a person over a live URL.

Autologin is the solution: a 1Password method for creating that first profile.

Connect a service account once, kick off autologin with a profile name and the service account, and a hosted agent reads the vault's Login items, attempts a sign-in for each one, reports the result per domain, and saves the result as a profile. Nobody has to be at a keyboard, and nobody has to paste a password into a script.

What autologin actually does

Your script sends a profile name and the ID of the service account to sign in with, never a credential. Browserless reads the Login items in the connected vault, resolves each username and password server-side, and fills them into the sign-in form inside the session.

The plaintext value never reaches your code, your environment variables, or your logs. Once a secret has loaded into the page, Browserless locks the session down: screenshots, live URLs, and page reads stay blocked for the rest of that sign-in session, and any in-progress screen recording is discarded. Session replay keeps recording, but the filled values are scrubbed from it before it's stored. They work normally again in the saved-profile sessions you run afterwards, which fill no secret.

When the sign-in succeeds, autologin saves the result as an ordinary Authenticated Profile. From that point on, it behaves exactly like a profile you created by hand: attach it with ?profile=<name>, and any supported session starts already signed in.

Why we built it

Authentication is usually the part that breaks browser automation and agent workflows. A scraper, an internal tool, or an AI agent will work until it hits a login wall, and then someone has to write bespoke sign-in code or paste a password into an env var they'd rather not manage.

We knew that our customers would benefit if their credentials were out of scripts and into a vault they already control. Autologin turns that first sign-in into one automated step instead of hand-built login code, and it keeps the credential inside 1Password the whole time.

Autologin handles the initial sign-in. Below, we cover how you can keep a saved profile fresh once the underlying site session expires.

Getting started

Connect a 1Password service account from your Browserless account under Profiles. Scope it to read-only access on the vault you plan to use, since Browserless only ever needs to resolve individual items, not manage the vault itself.

Once that's connected, kick off autologin with a profile name and the ID of the service account to sign in with. Profile names must be unique for your token. A name that already exists is rejected with a 400, and re-requesting a name that's still in flight returns the existing taskId rather than starting a duplicate. Autologin reads the Login items in the vault, so it already knows which sites to visit and which fields to fill:

const autologin = await fetch(
  `https://production-sfo.browserless.io/integrations/onepassword/profile?token=${process.env.BROWSERLESS_TOKEN}`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      name: "vendor-dashboard",
      integrationId: "op_int_0a1b2c3d4e5f6a7b8c9d0e1f",
      // optional: limit the run to a subset of the service account's sites
      // allowedDomains: ["https://example.com"],
    }),
  },
).then((res) => res.json());

console.log(autologin);
// { taskId: 'autologin_eef23c512148b7198564ff49' }

The task runs in the background, so poll it until state is success or failed:

const deadline = Date.now() + 5 * 60 * 1000;
let status;

do {
  if (Date.now() > deadline) throw new Error("Autologin timed out");
  await new Promise((r) => setTimeout(r, 3000));
  status = await fetch(
    `https://production-sfo.browserless.io/integrations/onepassword/profile/${autologin.taskId}?token=${process.env.BROWSERLESS_TOKEN}`,
  ).then((res) => res.json());
  console.log(status.state); // pending -> running -> success | failed
} while (status.state === "pending" || status.state === "running");

// { taskId: '...', state: 'success', profileName: 'vendor-dashboard', domains: [ ... ] }

if (status.state !== "success") {
  throw new Error(`Autologin failed: ${status.errorCode} ${status.errorMessage}`);
}

Once state is success, the profile is ready to use like any other:

const browser = await puppeteer.connect({
  browserWSEndpoint: `wss://production-sfo.browserless.io/chromium?token=${process.env.BROWSERLESS_TOKEN}&profile=vendor-dashboard`,
});

If the Login item includes a one-time-password (TOTP) field, autologin uses it automatically. Out-of-band factors like SMS codes and push approvals are out of reach for it, and it doesn't solve or bypass a CAPTCHA either. In both cases that domain needs a person: sign in manually over the same live-URL handoff used for manual profile creation.

How this compares to other credential bridges

A native 1Password bridge isn't unique to Browserless, but where our autologin differs is that it runs unattended, on any plan, with no 1Password desktop app in the loop:

Browserless autologinBrowserbase 1Password autofill
Runs without a person approving each sign-inYesNo, a person approves every request from the 1Password app
Available onAny plan, via the APIBrowserbase Director, in Early Access
Programmatic SDK pathSends a vault reference onlyPulls the secret into your code

Who this helps: both human and AI use cases

Developers and teams already using 1Password can get immediate benefits: browser automations and agent logins run through the vault instead of a secret pasted into a script or an env var.

With Browserless and 1Password, your agent logs in with credentials it never sees, backed by a vault you already use.

AI agents can also benefit from 1Password on Browserless. An agent that needs to work inside a logged-in tool still needs a way in. Autologin gives it one without ever putting a password in the agent's context.

Point autologin at the login page once, save the profile, and every agent session after attaches with ?profile=<name> - the same as a human-created profile would. The agent gets a signed-in browser, but never gets the credential.

Start with one login, skip the script

Autologin turns that first sign-in into something you configure once instead of something you build and maintain. Connect a vault, point it at a login page, and reuse the result across as many sessions as you need.

It slots into the same Authenticated Profiles system you may already be using, so nothing changes for sessions that don't pass an integration.

Get started with Browserless today.

1Password autologin FAQs

Does running autologin cost anything?

Yes. Autologin opens a real profile-creation session under your own token, so it's billed the same as any other session. Every run signs in from a residential IP, so expect normal session time plus residential proxy units. Stealth mode itself isn't billed separately.

What happens if the site uses a CAPTCHA or multi-factor authentication (MFA)?

Autologin handles TOTP-based MFA automatically when the Login item has a one-time-password field. It can't complete out-of-band factors such as SMS codes or push approvals, and it doesn't attempt to solve CAPTCHAs. When a domain hits either, sign in manually over the live-URL handoff used for manual profile creation, and save the profile from there instead.

Is my password ever stored in a log?

No. Your password is never written to the audit log. Each entry records the credential reference, the target origin, the selector it was filled into, and the outcome - never the value itself.

What happens when I rotate a password in 1Password?

The vault stays the single source of truth for the credential, so the next autologin run picks up the new value automatically. Profile names are unique, so delete the stale profile first, then re-run autologin with the same name to refresh it.