Monitor your login flow (and know before customers do)

Yes. Use a dedicated test user that authenticates through your SSO provider. For SAML-based SSO, the synthetic check flows through the same redirect dance a real user would.

For test accounts, set up a bypass policy or use TOTP with a known seed so the automation can generate valid codes. Never disable MFA for real users.

Start with one. If you serve users globally and login depends on region-specific infrastructure (CDN, SSO endpoints), add a second region later.

For TOTP-based MFA, use a dedicated synthetic test user whose second factor is stored in a secure secrets vault and generate time-based codes at runtime (never hardcode codes). For SMS/push MFA, prefer an alternate factor for the synthetic user (TOTP or backup codes) because SMS inbox and push approval aren’t reliably automatable. If your IdP supports it, create a “monitoring” policy that requires MFA but allows a stable factor (TOTP) and restrict the user by IP/device, least-privilege roles, and strict rate limits. Always separate synthetic users from real users and rotate secrets regularly.

Treat SSO as a multi-hop journey: app → IdP → app callback. Your checks should assert each redirect target (host + path), validate the final landing page, and capture cookies set on each domain. Common breakpoints include changed callback URLs, missing allowed redirect URIs, SameSite cookie changes, and IdP policy updates. Run at least one check against the full SSO flow and another against your “local login” (if you have it) so you can distinguish IdP outages from app regressions.

Add explicit assertions on redirect count and final URL. A redirect loop often manifests as repeated 302s between /login and /app (or /auth/callback). Best practice: fail the check if redirects exceed a threshold (e.g., >10) or if the journey revisits the same URL pattern multiple times. Also assert that a post-login session cookie is present and that a known authenticated element appears (e.g., user avatar, account menu). Screenshots at each step make it obvious whether the user is stuck at an IdP consent screen, a CSRF error page, or a blank callback route.

Validate the presence and attributes of the cookies that represent authentication/session state: domain scope (apex vs subdomain), Secure flag (required on HTTPS), HttpOnly, SameSite (Lax/None), and TTL/expiry behavior. Many real-world failures come from cross-site redirects in SSO combined with SameSite=Lax or missing SameSite=None;Secure on third-party contexts. Also watch for environment mismatches (cookie domain set to staging.example.com while running on app.example.com) and clock skew causing immediate expiry.

Use a dedicated monitoring account, keep run frequency reasonable (e.g., every 5–15 minutes per region), and configure stable IP ranges if your WAF supports allowlisting. Add realistic pacing between steps and retry logic only on network/transient failures (don’t brute-force). Ensure lockout policies exclude the synthetic user or set a higher threshold, and alert on repeated failures to prevent the check from repeatedly failing and escalating to a lockout. If you use Cloudflare/Datadog/WAF challenges, configure a bypass rule for the synthetic user’s path or tokenized header.

At minimum: (1) correct page title/heading for login, (2) successful form submission response/redirect, (3) session established (cookie/local storage token present), (4) authenticated UI element visible, (5) critical API call returns 200 (e.g., /me or /session), and (6) no console errors for key routes (optional but useful). Also assert performance thresholds (e.g., login completes <5s) so you catch slowdowns before they become timeouts.