How to keep Authentication state fresh across long Playwright CI runs

Before you start

• A Playwright Test project that already authenticates successfully with a setup project or fixture.

• A dedicated test identity approved for automation. For parallel tests that change shared data, plan for more than one test account.

• Authentication credentials supplied through your CI secret store or environment variables, never hard-coded in the repository.

• A rough understanding of your application or identity-provider session lifetime. If you do not know it, ask the identity team or observe when a test session is normally forced back to sign-in.

• A Continuous Integration (CI) pipeline, such as Azure DevOps or Jenkins, where each job or shard can run Playwright authentication before the business tests begin.

Why can authentication fail halfway through a CI run?

In this guide, CI means a Continuous Integration system such as Jenkins or Azure DevOps that triggers and runs your Playwright tests automatically.

When a setup test saves storageState, it captures the browser state at that moment. New browser contexts can start from that snapshot, but Playwright does not refresh an expired auth-state file for you. Your application may refresh tokens inside a live browser session if its authentication design supports that, but you should not assume a saved state file will remain valid for an entire long-running pipeline.

Here is what that can look like during one Playwright run triggered by Azure DevOps, Jenkins, or another CI system:

What changed? The test code may be unchanged. The saved authentication state has simply outlived the session or token lifetime enforced by the application or identity provider.

How do I keep Playwright storageState fresh in Azure DevOps?

Regenerate authentication state at the start of every CI job

If your pipeline currently restores playwright/.auth/user.json from a cache or an artifact created by an earlier run, stop doing that. Run the authentication setup inside the current job so the state is created as close as possible to the tests that use it.

Azure DevOps example: run the same Playwright authentication setup in CI

trigger:
- main
pool:
  vmImage: 'ubuntu-latest'
steps:
- task: UseNode@1
  inputs:
    version: '22.x'
  displayName: 'Use Node.js'
- script: npm ci
  displayName: 'Install dependencies'
- script: npx playwright install chromium --with-deps
  displayName: 'Install Chromium'
- script: |
    rm -rf playwright/.auth
    npx playwright test --project=chromium
  displayName: 'Run Playwright with fresh authentication'
  env:
    APP_URL: $(APP_URL)
    SSO_USER: $(SSO_USER)
    SSO_PASSWORD: $(SSO_PASSWORD)

This pipeline uses the same auth.setup.ts and playwright.config.ts from the earlier sections. Because the setup project is a dependency of the chromium project, Azure DevOps starts the current job, installs the required browser, removes any stale local auth state, runs the authentication setup, and then runs the business tests with freshly created state.

Azure DevOps secret handling: Create APP_URL as a normal pipeline variable. Store SSO_USER and SSO_PASSWORD as secret variables or retrieve them from Azure Key Vault, then map them into the test step through env as shown above. Do not place the credentials directly in azure-pipelines.yml, and do not publish playwright/.auth as a pipeline artifact.

Which authentication freshness pattern should you use?

Advanced Playwright patterns for longer or parallel suites

The Azure DevOps example above is enough for many teams. Use the following patterns only when the way your suite runs creates an additional authentication boundary.

Give each CI shard fresh authentication

If one CI job is long enough for authentication to become stale, split the suite into shards. Each shard is its own CI job, so it can run authentication near the beginning of its own execution rather than sharing a state file created much earlier.

Run four independent shards

npx playwright test --shard=1/4
npx playwright test --shard=2/4
npx playwright test --shard=3/4
npx playwright test --shard=4/4

In a real CI system those commands normally run on separate jobs or machines. Let the setup project run inside each shard. Avoid a design where one “authentication job” creates user.json and every shard downloads the same file if session freshness is already a problem.

Use one authenticated account per worker when tests change shared data

A single shared account works when tests can run at the same time without changing each other's server-side state. When tests create, edit, or delete shared data, Playwright recommends authenticating once per worker with a unique account.

Worker-scoped authentication pattern

import { test as base } from '@playwright/test';
import path from 'path';
export const test = base.extend<{}, { workerStorageState: string }>({
  storageState: ({ workerStorageState }, use) => use(workerStorageState),
  workerStorageState: [async ({ browser }, use) => {
    const id = test.info().parallelIndex;
    const authFile = path.resolve(
      test.info().project.outputDir,
      `.auth/${id}.json`
    );
    const account = await acquireAccount(id); // your account-pool logic
    const page = await browser.newPage({ storageState: undefined });
    // Complete your approved login flow with account.username/password.
    // Wait until the signed-in application state is visible.
    await page.context().storageState({ path: authFile });
    await page.close();
    await use(authFile);
  }, { scope: 'worker' }],
});

The important idea is not the helper function itself. Each worker gets its own account and creates its own state under the current run output. The tests inside that worker reuse the state without fighting another worker for the same account.

If UI login is slow: Use API authentication when your application supports it

For CI, a supported authentication API is often faster and less brittle than replaying a full login UI. Playwright can authenticate with APIRequestContext and save the resulting browser state in the same way.

tests/auth.setup.ts

import { test as setup } from '@playwright/test';
const authFile = 'playwright/.auth/user.json';
setup('authenticate by API', async ({ request }) => {
  await request.post(process.env.AUTH_URL!, {
    data: {
      username: process.env.SSO_USER,
      password: process.env.SSO_PASSWORD,
    },
  });
  await request.storageState({ path: authFile });
});

If one test exceeds the session lifetime: do not silently re-login

If a single business test runs longer than the session lifetime, automatically signing in again halfway through the test can hide a real session-expiry problem and change what the test is validating. A clearer design is to split the journey into smaller independent tests, or work with the application team on an explicit supported refresh mechanism.

At test boundaries, fail with a useful message if the application unexpectedly returns to sign-in. That makes the pipeline tell you “authentication expired” instead of producing a series of unrelated locator failures.

When does authentication become CI infrastructure?

Playwright can handle each of the cases above. The additional work sits around the business tests: refresh timing, test-user pools, worker-to-account mapping, secrets, state handling across CI jobs, and browser/runtime setup. When several of these become permanent parts of the pipeline, authentication has become shared CI infrastructure rather than a small login helper.

These are valid Playwright engineering patterns. The practical decision is whether QA authors should keep owning this setup or whether more of the authoring and execution workflow should live in the testing platform.

How does Leapwork Play change the authentication-freshness problem?

In Play, the SSO journey can be recorded once as a reusable LoginSSO test case. A business test that references LoginSSO runs that login flow before continuing with its own steps in Play's cloud browser. The login is a visible shared test asset rather than a JSON authentication-state file wired into the Playwright project.

For long CI runs, this changes the freshness boundary. A referenced login can create a new signed-in browser session at the beginning of the business test instead of relying on a state file created much earlier in the pipeline. storageState can still be faster while it remains valid because it can skip the login UI. Play reduces the setup and maintenance the QA author has to manage directly.

Trigger a Play RunList directly from CI

The CI pipeline does not have to be the machine that runs Playwright. With the Play API, Azure DevOps, Jenkins, or another CI system can trigger a Play RunList and let Play execute the test cases in its managed cloud environment.

For this Play execution path, the CI agent does not need the Playwright runtime, browser binaries, or commands such as npx playwright install --with-deps. Play runs the RunList test cases in separate short-lived execution containers. The pipeline still owns the trigger, secure API credential, network access, environment or test-data inputs, and the rule that decides whether a failed Play run should stop deployment.

Use the reusable login at the test boundary

• Record the approved SSO journey once and save it as LoginSSO.

• Create the business test that needs an authenticated session.

• Add “Use test case: LoginSSO” before the business-specific steps.

• Run the test in Play. The referenced login executes first, then the business journey continues.

Play records LoginSSO once and reuses it by reference. The images demonstrates reuse

Playwright vs Leapwork Play for long CI authentication

When should you consider moving this workflow to Play?

Consider Play when the authentication setup around the tests is becoming a recurring engineering responsibility, especially when QA authors are maintaining refresh logic, worker-scoped fixtures, test-user pools, CI browser setup, or sensitive state artifacts. Play keeps the login as a reusable test asset and moves browser authoring and execution into the shared Play environment.

Best practices

• Know the session lifetime you are designing for. A 15-minute access token and an 8-hour refresh session are very different CI problems.

• Generate authentication close to where tests run: per job, shard, or worker rather than once for the whole pipeline.

• Never hard-code usernames, passwords, client secrets, tokens, or OTP seeds. Use environment variables or a secret manager and mask values in CI logs.

• Keep storage-state files out of source control, persistent caches, and normal CI artifacts.

• Use separate accounts when parallel tests modify shared server-side data.

• Prefer a supported authentication API when it is more reliable than the login UI.

• Do not weaken MFA or Conditional Access simply to make automation pass.

• Do not silently reauthenticate in the middle of a test unless the scenario explicitly requires and validates that behavior.