- The application code is exactly the same in prod and preview environments. The only thing that changes is the OAuth provider configuration (endpoints, secrets, etc.), not the auth flow itself.
- The mock lets you specify a user ID / username directly on the sign-in screen, without real credentials or email verification. That makes it usable both for humans testing previews and for agents or automated test suites.
- It also lets us simulate third-party identity providers (Google, etc.) without actually integrating with them in previews. Dealing with things like captchas or provider-side enforcement in ephemeral environments is another source of friction we wanted to avoid.
It’s not real auth, but it keeps previews fully functional and avoids special-casing large parts of the app just to make OAuth work with dynamic URLs.
Comments
We’ve ended up solving this with an OAuth mock.
The main advantages for us:
- The application code is exactly the same in prod and preview environments. The only thing that changes is the OAuth provider configuration (endpoints, secrets, etc.), not the auth flow itself.
- The mock lets you specify a user ID / username directly on the sign-in screen, without real credentials or email verification. That makes it usable both for humans testing previews and for agents or automated test suites.
- It also lets us simulate third-party identity providers (Google, etc.) without actually integrating with them in previews. Dealing with things like captchas or provider-side enforcement in ephemeral environments is another source of friction we wanted to avoid.
It’s not real auth, but it keeps previews fully functional and avoids special-casing large parts of the app just to make OAuth work with dynamic URLs.