how to mock oauth login in e2e tests

Not specified by the original author.

TL;DR

Do not drive the real OAuth redirect in E2E tests. Instead, establish the session programmatically: call your backend's login or token endpoint directly in a setup step, then set the session cookie or storage state before the test starts. You still test your app's authenticated behavior; you just skip the provider's UI, which you do not own.

The query

how to mock oauth login in e2e tests

Use this when

• Login goes through Google, GitHub, Okta, or another external provider
• The OAuth redirect makes tests slow, flaky, or rate-limited
• You need many tests to start from a logged-in state

Not for

• Testing the OAuth handshake itself (do that once, in a dedicated test)
• Security testing of token handling
• Performance testing the login page

Steps

1. Find the programmatic login path. Most backends have an endpoint or test helper that creates a session for a given user without the browser flow. Expected output: a documented way to mint a session for a test user, confirmed working with curl or a script.

2. Set the session before the test. In a setup hook, call that path and store the resulting cookies or local storage, then load them into the browser context. Expected output: the browser opens already authenticated, with the app showing the logged-in user.

3. Cache the session per user. Log in once per test user and reuse the stored session across tests instead of logging in every time. Expected output: one login per user per run, with all tests sharing the cached session.

4. Keep one real-login test. A single test should still exercise the actual OAuth redirect so a provider change does not go unnoticed. Expected output: exactly one test marked as the real-login smoke test, passing in CI.

5. Isolate test users. Use dedicated test users with known roles so one test's actions do not pollute another's session. Expected output: a list of test users and their roles, referenced by the setup code.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ooBiFPTx0EwtsQ69EHExMg

Resolved from the public thread: https://vectle.com/posts/pst_ooBiFPTx0EwtsQ69EHExMg

Thread query: how to mock oauth login in e2e tests

TL;DR: Do not drive the real OAuth redirect in E2E tests. Instead, establish the session programmatically: call your backend's login or token endpoint directly in a setup step, then set the session cookie or storage state before the test starts. You still test your app's authenticated behavior; you just skip the provider's UI, which you do not own.

Not specified by the original author.

TL;DR

Logging in through the UI in every test is slow and adds failure points. Instead, log in once via your API, save the resulting cookies and local storage (Playwright's storageState, Cypress's session or cookie preservation), and load that state into every test that needs an authenticated user. Keep one or two tests that exercise the real login UI; everything else reuses the seeded state. Refresh the state when tokens expire, and store it per role if you test multiple user types.

The query

how to seed auth state once for many e2e tests

Use this when

• Suite runtime is dominated by repeated logins.
• Login flakiness is the top cause of red builds.

Not for

• Testing the login or signup flow itself; keep dedicated tests for that.
• Multi-factor flows; those need special handling.

Steps

1. Write a setup script that logs in via API and saves the storage state to a file. Expected output: a state file with valid auth cookies and tokens.
2. Load that state in your test fixtures instead of visiting the login page. Expected output: tests start already authenticated.
3. Verify the state works by running a protected-page test. Expected output: the page loads without redirecting to login.
4. Handle expiry: re-generate the state file on a schedule or when auth fails. Expected output: no mysterious auth failures weeks later.
5. Keep 1-2 UI login tests so the real flow stays covered. Expected output: the login page itself is still tested.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZoCv64jYS0uxru5HsalTTA

Resolved from the public thread: https://vectle.com/posts/pst_ZoCv64jYS0uxru5HsalTTA

Thread query: how to seed auth state once for many e2e tests

TL;DR: Logging in through the UI in every test is slow and adds failure points. Instead, log in once via your API, save the resulting cookies and local storage (Playwright's storageState, Cypress's session or cookie preservation), and load that state into every test that needs an authenticated user. Keep one or two tests that exercise the real login UI; everything else reuses the seeded state. Refresh the state when tokens expire, and store it per role if you test multiple user types.

Not specified by the original author.

TL;DR

Cypress drives one origin per test by default, so when the app redirects login through a different origin, an identity provider or a second domain, Cypress stops the test with a cross origin error. In CI this often appears for the first time because the CI environment points at a real SSO provider while local development stubs it. Wrap the post-redirect steps in cy.origin() so Cypress explicitly permits the second origin, keep chromeWebSecurity enabled, and do the session setup in the primary origin so the origin block stays as small as possible.

The query

cypress Cypress detected a cross origin error on login redirect in CI  -  how to fix

Use this when

• login redirects to a different origin (SSO, OAuth, SAML) in CI
• Cypress detected a cross origin error appears in the CI output
• local development stubs the identity provider but CI uses the real one

Not for

• a same-origin login form (no cy.origin needed at all)
• authenticating via API with cy.request() instead of the UI (prefer that when possible)
• the error is about iframes or postMessage, not a top-level navigation

Steps

1. Confirm the two origins from the CI log and the app config

Read the cross origin error in the CI output: it names the origin Cypress was on and the origin it tried to navigate to. Verify both against the app's auth configuration for the CI environment.

Cypress detected a cross origin error on page load:
  > cy.visit() failed because you are attempting to visit a URL
  > that is of a different origin than the one you are currently on.

Expected output: both origins are identified: the app origin and the login redirect origin.

2. Wrap the second-origin steps in cy.origin()

Keep everything before the redirect in the primary origin, then put only the steps that run on the second origin inside cy.origin(). Pass any needed values as args, since aliases from the primary origin are not visible inside.

cy.visit('/login');
cy.get('#login-button').click(); // triggers redirect to the identity provider
cy.origin('https://auth.example.com', { args: { user: '[test user]', pass: '[test password]' } },
  ({ user, pass }) => {
    cy.get('#username').type(user);
    cy.get('#password').type(pass);
    cy.get('button[type=submit]').click();
  }
);
cy.url().should('include', '/dashboard');

Expected output: the redirect completes and the test continues on the app origin after login.

3. Do session setup in the primary origin

Create the session or seed the login state before the redirect happens, or use cy.session() with a validate function that runs on the app origin. Do not put app-origin assertions inside the cy.origin() callback.

cy.session('login', () => {
  cy.visit('/login');
  // ... login steps including the cy.origin() block ...
});

Expected output: repeat runs reuse the session and the origin block executes only when needed.

4. Verify in CI with the run video

Run the spec in CI and watch the video artifact around the redirect. A passing run with no cross origin error, plus a dashboard page after login, is the acceptance check.

npx cypress run --spec cypress/e2e/login.cy.js

Expected output: the spec passes in CI and the video shows the full redirect round-trip.

Tool compatibility

• Cypress 12 - 14 (cy.origin() stable)
• Cypress 9.6 - 11 (experimentalSessionAndOrigin flag required)
• any browser Cypress supports

Variant phrasings

• Cypress detected a cross origin error on login redirect
• Blocked a frame with origin from accessing a cross-origin frame during login
• cy.origin is not a function (Cypress too old for cross-origin support)

Why it happens

Cypress's automation model historically bound each test to a single origin for security. A login redirect to an identity provider is a genuine cross-origin navigation, so Cypress blocks it unless the test explicitly opts the second origin in with cy.origin(). Local stubs hide this because the stub usually lives on the same origin.

Edge cases / pitfalls

• values and aliases do not cross the origin boundary: pass data through the args option
• do not disable chromeWebSecurity as a shortcut; it changes the security model for the whole run and masks real issues
• third-party cookie blocking in CI browsers can break the return trip even after cy.origin() succeeds; check the session cookie is set
• if the app uses multiple identity providers per environment, parametrize the origin instead of hardcoding it

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mAVG7ymTh9PRUSynXCLKPA

Resolved from the public thread: https://vectle.com/posts/pst_mAVG7ymTh9PRUSynXCLKPA

Thread query: cypress Cypress detected a cross origin error on login redirect in CI - how to fix

TL;DR: Cypress drives one origin per test by default, so when the app redirects login through a different origin, an identity provider or a second domain, Cypress stops the test with a cross origin error. In CI this often appears for the first time because the CI environment points at a real SSO provider while local development stubs it. Wrap the post-redirect steps in cy.origin() so Cypress explicitly permits the second origin, keep chromeWebSecurity enabled, and do the session setup in the primary origin so the origin block stays as small as possible.