OAuth Test Fixtures Need a Trust Boundary

OAuth integration tests often look harmless: create a user, authorize an application, receive a callback, and assert that the session exists. It is the test fixture that quietly crosses a trust boundary.

An old inbox, a shared client secret, or a callback URL copied from staging can turn a convenient test into a source of leaked identity data. This is especially easy to miss when a team uses a disposable address or tries to get temporary email for a fast setup, then lets that address live longer than the test run.

The hidden trust boundary in an OAuth test

An OAuth test involves more parties than its assertions suggest:

1. The application under test.
2. The authorization server, or a realistic test double.
3. The browser or automation runner.
4. The mailbox that receives verification or recovery messages.
5. The CI system that stores logs and artifacts.

Each party can see a different slice of the identity. A fixture is safe only when the slices are intentionally scoped to one run. If two jobs share a mailbox, a callback can consume the other job's authorization code. If a CI log prints the full redirect URL, a short-lived code may still become a durable artifact.

I use a simple rule here: a test identity may be reused inside one test scenario, but not across unrelated runs. The boundary are the run ID, the browser context, and the mailbox lease together.

For background on finding these assumptions before launch, see this threat-model email verification before release. The same discipline works for OAuth fixtures.

A small threat model

Before writing helpers, list what can go wrong and what the test should prove.

Asset	Failure mode	Useful control
Authorization code	Captured in logs or another job	Redact URLs and bind state to a run
Test identity	Reused by a parallel job	Generate a unique subject and mailbox lease
Refresh token	Stored in a CI artifact	Keep it in memory and revoke after the test
Verification message	Read by the wrong scenario	Filter by run ID and expire the lease
Redirect URI	Accepted outside the test client	Register exact, environment-specific URIs

This is not about making a fake provider perfectly secure. It is about making accidental cross-talk visible. A fixture that fails closed gives a useful signal; one that silently accepts the wrong user creates false confidence.

Design the fixture around a run identity

Create one opaque run identity at the start of the test. It should be safe to place in a test label, but it should not contain an email address, access token, or personal data.

type OAuthFixture = {
  runId: string;
  subject: string;
  mailboxLease: string;
  redirectUri: string;
};

const fixture: OAuthFixture = {
  runId: `ci-${process.env.GITHUB_RUN_ID}-${crypto.randomUUID()}`,
  subject: `oauth-test-${crypto.randomUUID()}`,
  mailboxLease: "lease-created-by-the-test-harness",
  redirectUri: "https://oauth.test.example/callback"
};

The run ID should travel through the provider state, the test user's display name, and the message filter. It is a correlation value, not a secret. Keep secrets in the test runner's secret store and never put them in state or query parameters.

Some teams add a prefix like tempail when naming temporary fixtures. That can be fine as a label, but a label is not isolation. The isolation comes from a unique lease and from rejecting messages that do not carry the expected run identity.

Bind consent and callbacks to the same run

The state value is often treated as a box-checking detail. In a test harness it can be the link between the browser session and the authorization request. Store a server-side record keyed by a hash of state, containing the run ID, client ID, redirect URI, and an expiration time.

At callback time, require all of these to match:

• The state has not been consumed.
• The client ID is the one created for this run.
• The redirect URI is the exact URI registered for the test environment.
• The browser session owns the expected run ID.
• The authorization code has not already been exchanged.

Do not make the test more permissive because a local callback is inconvenient. A permissive callback in a fixture tends to become a permissive callback in an application example, and that copy-paste risk is realy easy to overlook.

The same idea applies to inboxes. These session boundaries for test inboxes should be treated as part of the OAuth fixture, not as a seperate utility owned by another team.

Keep email data useful but disposable

Email is often needed to activate the test identity, but the message itself should have a short and explicit life. Store only the fields needed for the assertion: message ID, recipient lease, run ID, and a redacted link or token hash. Delete the raw body after extraction where the provider allows it.

Avoid matching only on a subject such as “Verify your account.” Parallel tests can produce identical subjects. Match the leased recipient and run marker, then fail if more than one message is eligible. A dummy e mail entry in a fixture file may pass a smoke test, but it can hide a broken delivery filter in a real parallel run.

A few practical safeguards help:

• Never use a production mailbox for OAuth tests.
• Do not persist refresh tokens with screenshots or traces.
• Redact query strings before uploading browser artifacts.
• Expire unused mailbox leases, even after a failed job.
• Revoke test grants in teardown, with a bounded retry.

A cleanup job that doesnt finish should still leave expired leases and unusable tokens behind it.

The cleanup wont always succeed when CI is cancelled. That is why leases and tokens need server-side expiry as well, not just a best-effort teardown.

A practical review checklist

Before merging an OAuth fixture, ask:

• Can two parallel runs ever select the same identity or message?
• Is the callback URI exact, environment-specific, and checked again at exchange time?
• Does state bind the browser, client, and run together?
• Are authorization codes, tokens, and raw email bodies absent from artifacts?
• Does a mismatched message fail the test instead of being skipped?
• Is cleanup safe to retry and bounded in time?
• Are expired fixtures unusable even when teardown is interrupted?

The goal is not to make tests elaborate. It is to give each test a small, explicit trust boundary. When an OAuth fixture owns its identity, consent, callback, and mailbox lease, failures become easier to explain—and a passing test says something more trustworthy about the application.