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.…