How to test OAuth and SSO flows end-to-end in CI

Approach 1: Playwright + test IdP accounts

1. 1.Create dedicated test accounts on each OAuth provider (Google Workspace test user, GitHub machine user, Okta dev tenant) - never use personal accounts for CI
2. 2.Use Playwright's storageState to cache authenticated sessions - authenticate once in a setup project, then reuse the session across all tests that need auth
3. 3.Handle OAuth redirects with page.waitForURL() to track the redirect chain: your app -> provider login -> consent screen -> your app callback
4. 4.For popup-based flows (Google One Tap, GitHub OAuth popup), use page.waitForEvent('popup') to capture the popup window and interact with it
5. 5.Store test credentials in CI secrets (GitHub Actions secrets, CircleCI contexts) - never commit OAuth tokens or passwords to your repo
6. 6.Run auth-dependent tests sequentially, not in parallel, to avoid rate limiting from identity providers

OAuth with social login providers (Google, GitHub)

The core challenge with OAuth testing is the cross-origin redirect. When a user clicks "Sign in with Google," the browser navigates from your domain (app.example.com) to accounts.google.com, then back to your domain's callback URL. During this redirect, Playwright's page context changes origin, which means any locators targeting your app's DOM are invalid until the browser returns. For Google OAuth, you need a dedicated test account in a Google Workspace you control. Using a personal Gmail account in CI is fragile: Google may trigger CAPTCHA challenges, require phone verification, or flag the account for suspicious activity when it logs in from a new IP (your CI runner) every few minutes. Create a Workspace test user, disable 2FA for that user (or use an app password), and add the CI runner's IP range to your Workspace's trusted networks. GitHub OAuth is simpler because GitHub machine users are designed for automation. Create a machine user, generate a personal access token with the scopes your app requires, and pre-authorize your OAuth app for that user so the consent screen does not appear during tests. Skipping the consent screen reduces test flakiness from UI changes on GitHub's side. The Playwright approach for a redirect-based OAuth flow uses page.waitForURL() to track the redirect chain. After clicking the login button, wait for the URL to match the provider's domain, interact with the provider's login form, then wait for the redirect back to your app. The code below shows this pattern for Google OAuth. Session caching with storageState is critical for test suite performance. Without it, every test that requires authentication runs the full OAuth flow, which adds 5-15 seconds per test and hammers the identity provider with login requests. Playwright's storageState serializes cookies and localStorage to a JSON file after the first authentication, then restores that state before subsequent tests. Run the OAuth flow once in a global setup project, save the state, and reuse it across your entire suite.

import { test, expect } from "@playwright/test";
import path from "path";

const AUTH_FILE = path.join(
  __dirname, ".auth", "google-user.json"
);

// Global setup: authenticate once, save session
test("authenticate with Google OAuth", async ({ page }) => {
  // Navigate to your app's login page
  await page.goto("https://staging.example.com/login");

  // Click the Google login button
  await page.getByRole("button", {
    name: "Sign in with Google"
  }).click();

  // Wait for redirect to Google's login page
  await page.waitForURL("**/accounts.google.com/**");

  // Fill Google credentials
  await page.getByLabel("Email or phone").fill(
    process.env.GOOGLE_TEST_EMAIL!
  );
  await page.getByRole("button", { name: "Next" }).click();

  await page.getByLabel("Enter your password").fill(
    process.env.GOOGLE_TEST_PASSWORD!
  );
  await page.getByRole("button", { name: "Next" }).click();

  // Handle consent screen if it appears
  // (pre-authorized apps skip this)
  const consentButton = page.getByRole("button", {
    name: "Allow"
  });
  if (await consentButton.isVisible({ timeout: 3000 })
      .catch(() => false)) {
    await consentButton.click();
  }

  // Wait for redirect back to your app
  await page.waitForURL(
    "**/staging.example.com/dashboard**"
  );

  // Verify authentication succeeded
  await expect(
    page.getByText("Welcome")
  ).toBeVisible();

  // Save session state for reuse in other tests
  await page.context().storageState({ path: AUTH_FILE });
});

// Subsequent tests reuse the saved session
test.use({ storageState: AUTH_FILE });

test("authenticated user can access settings",
  async ({ page }) => {
    // No login needed - session restored from file
    await page.goto(
      "https://staging.example.com/settings"
    );
    await expect(
      page.getByRole("heading", { name: "Settings" })
    ).toBeVisible();
  }
);

Token refresh and session edge cases

The authentication flows most teams do not test are the ones that break in production at 2 AM: expired access tokens that should silently refresh, refresh token rotation that invalidates old tokens, and concurrent tab behavior when one tab logs out while another is mid-action. Access token expiry is the most common untested scenario. Your app gets a short-lived access token (typically 15-60 minutes) and a longer-lived refresh token (days to weeks). When the access token expires, your app should use the refresh token to get a new access token without interrupting the user. If this refresh logic has a bug - a race condition, a missing error handler, a redirect loop - the user gets silently logged out or sees a cryptic error. This happens to real users every day, but most test suites never exercise it because tests run in under 60 minutes and the access token never expires. To test token expiry in Playwright, you manipulate the browser's cookies or localStorage directly. If your app stores the access token in a cookie, use page.context().addCookies() to set an expired token. If it uses localStorage, use page.evaluate() to modify the stored token. Then trigger an API call (navigate to a page that fetches data) and assert that the app refreshes the token and loads successfully instead of showing an error or redirecting to login. Refresh token rotation is a security feature where each use of a refresh token invalidates the old one and issues a new one. If your app sends the same refresh token twice (a race condition between two concurrent API calls), the second request gets rejected and the user loses their session. Test this by making two API calls in rapid succession after the access token expires. Concurrent tab behavior is another gap. Open your app in two tabs, log out in one, then perform an action in the other. Does the second tab gracefully redirect to login, or does it show a broken state? Open your app in two tabs, let the access token expire, and perform actions in both simultaneously. Does each tab refresh the token independently, or does the refresh token rotation cause one tab to invalidate the other's session? The "remember me" feature deserves its own test. When a user checks "remember me," what token lifetime does your app set? Does closing and reopening the browser maintain the session? Does it survive a browser cookie clear? These are the edge cases that enterprise security reviews will ask about, and having a test that validates them is better than guessing.

import { test, expect } from "@playwright/test";

// Test: expired access token triggers silent refresh
test("handles expired access token", async ({ page }) => {
  // First, log in normally to establish a session
  await page.goto("https://staging.example.com/login");
  await page.getByLabel("Email").fill("[email protected]");
  await page.getByLabel("Password").fill("testpass123");
  await page.getByRole("button", { name: "Log in" })
    .click();
  await page.waitForURL("**/dashboard");

  // Expire the access token by manipulating storage
  // Adjust based on your app's token storage method
  await page.evaluate(() => {
    // If using localStorage
    const authData = JSON.parse(
      localStorage.getItem("auth") || "{}"
    );
    // Set expiry to the past
    authData.accessTokenExpiry = Date.now() - 60000;
    // Alternatively, corrupt the access token
    authData.accessToken = "expired_token_value";
    localStorage.setItem("auth", JSON.stringify(authData));
  });

  // Navigate to a page that requires an API call
  // This should trigger the refresh flow
  await page.goto(
    "https://staging.example.com/dashboard/projects"
  );

  // Assert the page loads successfully
  // (token was refreshed in the background)
  await expect(
    page.getByRole("heading", { name: "Projects" })
  ).toBeVisible({ timeout: 10000 });

  // Verify no error messages or login redirects
  await expect(page).not.toHaveURL("**/login");
});

// Test: concurrent tabs handle session correctly
test("concurrent tabs after logout",
  async ({ browser }) => {
    const context = await browser.newContext();

    // Open two tabs with authenticated sessions
    const tab1 = await context.newPage();
    const tab2 = await context.newPage();

    // Log in on tab1
    await tab1.goto(
      "https://staging.example.com/login"
    );
    await tab1.getByLabel("Email")
      .fill("[email protected]");
    await tab1.getByLabel("Password")
      .fill("testpass123");
    await tab1.getByRole("button", { name: "Log in" })
      .click();
    await tab1.waitForURL("**/dashboard");

    // Tab2 shares the session (same browser context)
    await tab2.goto(
      "https://staging.example.com/dashboard"
    );
    await expect(
      tab2.getByRole("heading", { name: "Dashboard" })
    ).toBeVisible();

    // Log out on tab1
    await tab1.getByRole("button", { name: "Log out" })
      .click();
    await tab1.waitForURL("**/login");

    // Try to perform an action on tab2
    await tab2.getByRole("link", { name: "Settings" })
      .click();

    // Tab2 should redirect to login, not show an error
    await expect(tab2).toHaveURL(/\/login/,
      { timeout: 10000 }
    );

    await context.close();
  }
);

Common pitfalls

• —Do not disable CORS or security headers in your test environment to make auth tests easier - you will miss real security issues that only surface with proper headers enabled
• —Do not hardcode OAuth tokens or SAML assertions in your test files - tokens expire, and hardcoded values become stale without warning. Use CI secrets and test account credentials
• —Do not skip token refresh testing - expired access tokens that fail to refresh silently are one of the most common auth bugs in production, and they only surface after the token lifetime elapses
• —Do not skip SSO testing because it is complex to set up - SSO is how your highest-value enterprise customers authenticate, and a broken SSO flow after a deploy is a severity-1 incident