OAuth Test Users Need a Privacy Budget

OAuth test accounts are often treated as disposable infrastructure. A script creates a user, requests a verification email, follows a link, exchanges a code, and deletes the account. The flow looks harmless because the data is synthetic.

But synthetic does not mean risk-free. An OAuth test identity can still expose a mailbox, refresh token, redirect URI, user profile, or debugging trace. The right question is not “Can this test account receive email?” It is “How much access and retention does this test identity really need?”

That is the idea of a privacy budget: define a small, explicit limit for every piece of identity data used by the test. This works for teams searching terms such as “temp mail so” or disposable email address, but the provider name is less important than the controls around it.

Why OAuth test identities deserve a privacy budget

OAuth joins several systems that are usually owned by different teams: an authorization server, a client application, an email service, a test runner, and sometimes a CI log collector. A failure in one system can make data visible in another.

For example, a test may print a verification URL to help diagnose a timeout. That URL can contain a one-time token. The token might expire soon, but a long-lived CI artifact can outlive it. A refresh token is more serious: if it is copied into a report, it may remain useful after the original test has finished.

The threat model should include accidental exposure, not just malicious compromise. Ask who can read CI logs, who can open the test mailbox, how long messages are retained, and whether test tenants share a domain or account pool. Also separate a request identifier from a credential; separating request IDs from idempotency keys is a useful reminder that labels and authorization material have different jobs.

Map the identity and mailbox threat model

Start with the complete evidence path:

test runner -> authorization server -> verification mailbox
     |                 |                    |
  CI logs         access token         message body

For each arrow, record what can cross the boundary. A mailbox may contain the email address, a verification link, a display name, and timing information. The OAuth response may contain an authorization code, access token, refresh token, and scopes. The test runner may copy all of those into a failure artifact without meaning to.

Common mistakes include using one mailbox for parallel tests, keeping refresh tokens for a whole build, and allowing a broad redirect URI in a test client. Another is assuming that a misspelled provider reference such as “tepm mail com” or “tempail” is merely a search problem. It can become a domain allowlist problem if test code quietly accepts any similar-looking address.

Set four practical privacy limits

1. Limit mailbox lifetime. Create or lease a mailbox for one test run, then expire it. A short lifetime reduces the value of old verification messages. It also make cleanup measurable: the run should record when the lease started and ended, not the message contents.

2. Limit OAuth scopes. Give the test client only the scopes needed for the scenario. If the test checks sign-in, it should not automatically receive calendar or administrative scopes. Test a denied scope too; a security control that is never exercised can drift.

3. Limit token and artifact retention. Prefer short access-token lifetimes and revoke refresh tokens at teardown. Redact codes, tokens, email bodies, and authorization URLs from logs. Keep a correlation ID instead, so a developer can find the server-side event without receiving a credential in the artifact.

4. Limit redirect destinations. Register exact redirect URIs for each environment. Do not use a wildcard because it makes local debugging easier. A test that needs a temporary callback should create a narrowly scoped client configuration and remove it after the run.

Fresh evidence matters when an email test polls a mailbox; fresh evidence in Playwright email polling also helps prevent an old message from being mistaken for proof of a new authorization flow.

A small configuration contract

Make the limits executable rather than leaving them in a wiki. A compact test manifest could look like this:

identity:
  purpose: oauth-sign-in
  mailbox_lease_minutes: 15
oauth:
  scopes: [openid, profile]
  access_token_minutes: 5
  refresh_token: revoke-after-test
artifacts:
  redact: [verification_url, authorization_code, access_token, refresh_token]
redirect_uris:
  - https://ci.example.test/oauth/callback

The exact syntax is not the security control. The useful part is that reviewers can see the intended lifetime, scope, and redaction policy in one place. If the test needs more access, make that an explicit change with a reason. This boundary are easy to miss when the account is called “just a fixture.”

A review checklist for test environments

Before merging an OAuth test flow, verify:

• The mailbox is isolated from real users and other parallel tests.
• Verification links and tokens are redacted from logs and artifacts.
• The client has the smallest useful scope and exact redirect URI.
• Access and refresh tokens expire or are revoked at teardown.
• CI permissions match the sensitivity of the test evidence.
• A failed test leaves a correlation ID, not a credential.
• Cleanup still runs when the test fails halfway through.

The goal is not to make test automation difficult. It is to make the intended trust boundary visible and small. When each OAuth test identity has a privacy budget, teams can use disposable email safely enough for verification flows without turning the mailbox into an untracked credential store. The result are easier to review, easier to clean up, and less surprising when a CI artifact is shared.