Some teams want to run their end-to-end tests without repeating the full login flow at every execution. When authentication is handled by an identity provider like Entra ID (formerly Azure AD), this can raise questions about reusing existing session cookies to speed things up.
Although manually re-injecting authentication cookies can work in theory, it is not recommended. This method often creates security risks and leads to unstable or hard-to-maintain tests.
The good news: there is a cleaner, safer, and fully controlled way to achieve the same “skip login” effect.
⚠️ Why injecting cookies directly is discouraged
Reusing or hard-coding authentication cookies presents several issues:
Session cookies are short-lived and may expire unexpectedly.
Injecting cookies manually can weaken security.
Identity providers such as Entra ID rotate tokens and enforce strict validation.
It often leads to flaky tests.
For these reasons, we do not recommend relying on raw cookie injection inside automated test flows.
✔️ Recommended approach: Build a dedicated “login-as-tester” endpoint
Instead of injecting cookies manually during test execution, the customer can implement a small, controlled mechanism on their side.
Concept
Create a private route, for example:
/login-as-tester
This endpoint performs the following steps:
Automatically logs in using a dedicated test account (not a production user).
Generates or retrieves the valid authentication cookies.
Injects those cookies into the active session.
Redirects the user or test runner to your app’s main page (for example:
/).
From this point on, your automated test begins already authenticated, without going through the standard login flow.
✨ Benefits of this approach
Controlled and secure test-only mechanism
No need to modify the automated scripts
No exposure of sensitive cookies in test code
More stable tests (no cookie expiration issues mid-run)
Maintains good security hygiene while supporting fast login for test runs
Example flow
Test runner opens:
https://your-app.com/login-as-testerThe backend handles authentication + cookie generation.
Automatic redirect to
/.Automated tests start from the authenticated state.
Conclusion
Thunders can run tests without performing the login flow each time, but this requires a secure and maintainable setup on the customer's side.
The recommended solution is to create a dedicated “login-as-tester” endpoint that handles authentication and cookie injection safely before tests begin.