OAuth Redirect Tests Need an Identity Boundary

OAuth tests often focus on the visible protocol steps: send the user to the authorization server, return to the callback, exchange the code, and inspect the token. That is necessary, but it leaves out a quieter dependency: the identity used by the test.

If every CI run reuses one account, inbox, or test tenant, the test is no longer checking one login flow. It is checking a shared history of logins, consent screens, verification messages, and old sessions. A passing result can hide a broken trust boundary.

I think of the test identity as part of the security boundary. It needs an owner, a short lease, and evidence that belongs only to the current run. This makes OAuth failures easier to explain and reduces the chance that a test accidentally exercises production-like data.

Why an OAuth test identity is part of the security boundary

Consider a test that creates a user, verifies an email, and completes an OAuth login. There are at least four actors and resources involved:

1. The application under test.
2. The identity provider and its client configuration.
3. The mailbox receiving the verification message.
4. The CI job that owns the resulting account and tokens.

The common mistake is to isolate only the browser session. The account and mailbox remain shared. That creates an account collision when two jobs run together, and it can also make a stale verification link look valid. The browser is clean, but the identity is not.

This is why a temporary disposable mail address can be useful in a controlled test environment. It is not a replacement for production email security, and it should never receive real user data. Its value is narrower: it gives a test an inspectable mailbox with a clear owner and an expiry policy.

A small threat model for redirect tests

Before adding more retries, write down what the test must prevent. My small threat model has these cases:

• Cross-run account use: job B logs in as the account created by job A.
• Stale verification: a link from an earlier run is accepted by the current run.
• Redirect confusion: the callback accepts an unapproved redirect URI or a value from another environment.
• Token leakage: access tokens, authorization codes, or mailbox contents are written to CI logs.
• Orphaned identity: a cancelled job leaves an account that later tests can discover.

The test does not need to solve every identity-provider problem. It should prove that its own boundaries are present. For example, bind the run ID to the account record, generate a unique state value, and verify that the callback rejects a mismatched state. Keep the state value out of screenshots and verbose logs, because it can still be useful to an attacker during its short lifetime.

The redirect URI deserves the same discipline. Test clients should have a small allowlist for the test environment. A wildcard callback may make local development convenient, but it makes a typo or an environment mix-up harder to detect.

Build a lease-based test identity

A lease is a simple ownership record with an expiration time. It does not need a large service. A database row or a CI artifact can record the minimum information:

{
  "run_id": "ci-8421",
  "identity_id": "oauth-test-8421",
  "mailbox": "[e-mail]",
  "created_at": "2026-10-22T01:00:00Z",
  "expires_at": "2026-10-22T02:00:00Z"
}

The important properties are ownership and expiry. Before using the identity, the test checks that the lease belongs to the current run. After the test, cleanup revokes sessions, removes the test user where supported, and marks the lease closed. A scheduled cleanup job should still remove expired records, because cancellation is normal in CI.

Do not put a real password in the artifact. Prefer an identity-provider API designed for test users, a secret reference managed by the CI platform, or a password generated inside the job and discarded after use. The test should also fail closed if it cannot prove that the account is new or owned by the current run.

For UI coverage, Playwright checks for signup emails provide a useful way to inspect the message without coupling the test to a developer's inbox. The same boundary should apply to the browser context: one context per lease, with cookies and local storage deleted after the run.

Keep email verification evidence isolated

Email is often treated as a side effect, but in this flow it is an authentication input. The test should assert the message identity, recipient, freshness, and intended action. It should not merely search for the newest message in a shared inbox.

Use a correlation value that is safe to expose to the test runner, such as a generated user ID. Then verify that the message belongs to that user and was created after the lease started. A freshness check for signup verification helps prevent an old message from satisfying a new run.

Keep the email body out of normal CI output. Save a redacted assertion artifact instead: subject matched, recipient matched, link host matched, and age was within the allowed window. This gives the team evidence without turning every failed build into a collection of personal-looking data. The wording in logs doesnt need to be fancy, it needs to be consistent.

Search terms such as tempmailso, temp mail generator, and even tamp mail com may appear in fixtures or documentation. They are not identity controls. If a team uses a temporary disposable mail service for isolated testing, document its retention and access rules seperately from the OAuth configuration.

A practical checklist for CI

Before calling an OAuth test reliable, check these items:

• The test account and mailbox have a unique run owner.
• The lease has a short expiry and cleanup can run after cancellation.
• The redirect URI is an exact allowlist entry for the test environment.
• The state value is generated per attempt and mismatches are rejected.
• Verification email checks include recipient, freshness, and correlation.
• Tokens, codes, passwords, and mailbox bodies are excluded from logs.
• A failed setup does not fall back to a shared account.
• The cleanup result is recorded, even when the main assertion occured earlier.

The goal is not to make every test elaborate. It is to make the security assumptions visible. Once the identity has a clear boundary, a failing redirect test points to a smaller set of causes: callback configuration, state handling, account provisioning, or email evidence. That is a much better signal than a green test built on yesterday's session.