Skip to main content
SSO logins are hard to automate: providers deliberately detect and block automated browsers. The pattern that avoids bot detection is to authenticate once by hand or through a controlled account, save the session, and load it in tests. Never automate the provider’s login page on every run.

​
The pattern

​
Save the session once

Write a test whose only job is to hold a browser open while you log in manually, then save the state:
tests/setup/capture-sso.test.yaml
Run it headed (from the local editor, not headless CI), finish the SSO sign-in in the opened browser, and let the save step write sso-state.json. The file holds the cookies, localStorage, and IndexedDB state the session needs.
The state file is a live credential. Do not commit it to a public repo. Keep it out of git, deliver it to CI as a secret, and rotate it on the same schedule as the account’s sessions.

​
Load it in every test

tests/reports.test.yaml
authLoad injects the state before the first navigation, so the app sees an already-authenticated browser.

​
Keeping the session fresh

State files expire with the IdP session. Two options keep the session valid:
  • Refresh continuously. Add authSave to a test’s after: section so each run rolls the state forward:
    Continuous refresh works when the app slides session expiry on activity, but only where the file persists. In CI the save lands in the runner’s checkout and disappears when the job ends; to keep refreshed state across jobs, write it back yourself (upload it as an artifact a later job restores, or push it to your secret store from a scheduled workflow).
  • Re-capture on failure. When a run fails on the login wall, re-run the capture test. Put the capture step behind a weekly scheduled job or a manual workflow so staleness is a one-command fix.
For apps whose login is short-lived, consider a cached auth module (autoAuth: true) instead: Momentic stores the session server-side and shares it across parallel tests within a TTL. See cache authenticated sessions.

​
Automating the IdP

Sometimes there is no state shortcut: for example, testing the login flow itself. If you must drive the provider’s UI:
  • Use a dedicated test account with 2FA that accepts TOTP, not SMS or push. Generate codes in a javascript step with OTPAuth; see authenticator-app codes.
  • Expect bot detection on Google and Microsoft. Okta and Keycloak are usually permissive on dedicated test accounts.
  • Keep the login in one module so when it breaks, one file breaks.