OAuth 2.0 and SSO flows fail in automated testing for one reason: standard UI automation tools follow the browser through a multi-step redirect chain but cannot reliably capture tokens, assert on session state, or handle 2FA challenges that interrupt the login sequence. TestInspector solves this by combining HTTP request steps that assert on API responses with browser-based UI steps and encrypted {{TOTP:secret}} variables that generate one-time passwords inline—the entire authentication flow runs as a single test sequence without any code or framework configuration. For QA teams that need to validate identity provider integrations, token expiry handling, and post-login redirects, this gives functional coverage over the auth stack without requiring a test engineer who can write custom OAuth clients.

This guide covers how TestInspector’s HTTP steps, variable system, and session assertion model work together to test OAuth 2.0 authorization code flows, SAML SSO logins, and 2FA-protected authentication sequences. For background on how TestInspector fits into a broader automation strategy, see the TestInspector overview and Astaqc’s test automation services page.

What Makes OAuth 2.0 and SSO Flows Hard to Automate

The core difficulty with OAuth 2.0 automation is that the authorization code flow crosses at least two domains: your application and the identity provider (IdP). The user authenticates on the IdP’s login page, which is outside your application’s domain, and the IdP redirects back to your application with an authorization code in the URL. Standard browser automation tools handle same-domain interactions well but struggle with the redirect because the browser leaves your application’s domain mid-flow, making cookie and session state difficult to assert on, and the authorization code in the redirect URL is typically consumed immediately and never visible to the test runner.

SSO flows (SAML-based or OIDC-based) have an additional complication: the login page is often rendered by the IdP (Okta, Azure AD, Google Workspace, PingFederate), which the test runner may not be authorized to control. Any test that tries to fill in credentials on an Okta or Azure AD login page may encounter bot detection, rate limiting, or CAPTCHAs that break the test on the second or third run.

2FA adds a third layer: if the IdP enforces TOTP-based one-time passwords (Google Authenticator, Authy, or any RFC 6238 implementation), the test must generate a valid TOTP code at the time the form is submitted. Hardcoding a TOTP code in a test is never valid—the code expires every 30 seconds. The test must either generate the code programmatically from the TOTP secret or skip 2FA enforcement in the test environment, which creates a gap between what is tested and what runs in production.

These three factors—cross-domain redirects, IdP-controlled login pages, and time-based OTP challenges—are why most teams either skip auth flow automation entirely or maintain fragile, framework-heavy test suites that break on every IdP configuration change.

How TestInspector Handles OAuth 2.0 Redirect Flows

TestInspector approaches OAuth 2.0 testing through a combination of browser UI steps and HTTP request steps that can be sequenced together in a single test. For the portions of the auth flow that happen in the browser—clicking the “Sign in with Google” button, filling in credentials on the IdP login page, confirming consent screens—TestInspector uses its standard browser-based step execution running on Chrome, Firefox, Edge, or Safari. For the portions that are better validated at the HTTP level—checking that the authorization code exchange succeeded, asserting on the access token format, confirming that the API returns a valid session for the received token—HTTP request steps run inline within the same test sequence.

The HTTP request step in TestInspector supports GET, POST, PUT, PATCH, and DELETE methods with configurable headers, request bodies, and response assertions. For token validation, this means a POST step can send the authorization code to the token endpoint, capture the access token from the JSON response using variable extraction, and then pass that token as a Bearer header in subsequent HTTP steps that validate the session. The variable captured from step N is available in step N+1 without any custom scripting—the variable interpolation system handles the reference.

For teams whose application uses an authorization code flow with PKCE (Proof Key for Code Exchange), the test sequence covers: browser step to trigger the auth flow, HTTP step to assert on the token endpoint response, HTTP steps to validate the access token against protected API endpoints, browser steps to assert on the post-login UI state. This covers the full round-trip from click to authenticated session without requiring a custom OAuth client library.

Session Validation: Asserting Login State After Redirect

After the OAuth redirect completes and the user lands back in the application, most tests stop at “the correct page loaded.” This passes when the redirect worked but fails to catch a class of bugs where the session was created incorrectly: the token was stored in localStorage instead of a secure cookie, the session expiry was set to an incorrect value, or the user’s permissions in the application do not reflect what the IdP returned in the token claims.

TestInspector extends session validation through three mechanisms. First, browser-based assertions confirm the UI reflects the correct authenticated state: the user’s name appears in the header, the dashboard loads for the correct role, and role-restricted navigation items are visible or hidden as expected. Second, HTTP request steps can validate that authenticated API calls succeed after the login flow: a GET step with the session cookie or Bearer token in the header should return a 200 with the user’s profile data. Third, visual regression via SSIM screenshot comparison can confirm that the post-login view matches the baseline, catching UI state bugs where authentication succeeded but the interface rendered incorrectly.

For applications with multiple roles (admin, standard user, read-only), TestInspector’s suite-level variable scoping allows the same core test logic to run with different credential sets by parameterizing the username and password at the suite level. Each role’s credential pair is stored as an encrypted suite variable, and the test sequence references {{USERNAME}} and {{PASSWORD}} rather than hardcoded values. Running the suite against three role configurations validates that each role logs in successfully and lands in the correct post-login state.

Using TOTP Variables for 2FA-Protected SSO Flows

TestInspector’s {{TOTP:secret}} variable generates a valid TOTP code at test runtime from the base32 TOTP secret associated with the test account. This is the same calculation that Google Authenticator performs: an HMAC-SHA1 hash of the current Unix timestamp divided by 30, truncated to a 6-digit code. The result is a valid code for the 30-second window in which the test runs, which means the TOTP step assertion succeeds on any run, not just during the 30-second window when the code was recorded.

The TOTP secret is stored as an encrypted variable at the org, suite, or test level. The test references it as {{TOTP:MY_TOTP_SECRET}} in the step where the OTP code needs to be typed. TestInspector resolves the variable to the current valid code at execution time, types it into the OTP input field, and proceeds. The test does not need to be re-recorded when the TOTP secret is rotated—updating the encrypted variable value is sufficient.

For SAML SSO flows where the IdP enforces 2FA, the same TOTP variable applies: the test authenticates with the IdP’s login form, generates the TOTP code inline, and completes the 2FA challenge before the SAML assertion is posted back to the service provider. The test runner handles the timing automatically because the variable is resolved at the moment the step executes.

One practical consideration: for SSO flows where the IdP is a shared environment, test accounts must have TOTP configured and the TOTP secret must be accessible to the test runner. This is a setup step that must be performed once per test environment: create a dedicated test account in the IdP, enable TOTP, extract the base32 secret during setup, store it as an encrypted variable in TestInspector, and never rotate it independently of the test. If the production IdP enforces TOTP for all users but the test environment does not, the gap between environments creates a testing blind spot—tests pass in staging but auth flows could fail in production if the IdP configuration diverges.

CI/CD Integration for OAuth Flow Tests

TestInspector’s CI/CD trigger API allows auth flow test suites to run automatically as part of a deployment pipeline. The trigger is an HTTP POST to TestInspector’s API with the suite ID and optional variable overrides in the request body. This means a CI pipeline (GitHub Actions, GitLab CI, CircleCI, or any system that can make HTTP requests) can trigger an OAuth flow validation run after a staging deployment and gate the next pipeline step on the run result.

For authentication flows specifically, the most valuable CI integration point is post-deployment smoke testing: after deploying a new version of the application or a configuration change to the identity provider integration, a triggered TestInspector run validates that the OAuth redirect, token exchange, and post-login session work correctly in the new configuration. If the IdP’s client credentials were rotated, the redirect URI was changed, or the CORS policy was updated incorrectly, this run catches the failure before any users encounter it.

TestInspector also supports scheduling via cron, interval, and one-time triggers. For teams that need ongoing monitoring of their auth flow—particularly for applications that depend on external IdPs where outages or configuration drift can affect login without any deployment on your side—a scheduled run every 15 or 30 minutes confirms that the entire auth sequence works end-to-end and surfaces issues that might otherwise sit undetected until a user reports being unable to log in.

For teams using Claude Code, Cursor, or Claude Desktop to generate tests, TestInspector’s MCP tokens allow the AI assistant to create and modify test steps directly, including configuring HTTP steps for token endpoint assertions and setting up TOTP variable references. See the TestInspector product page for the current MCP integration documentation.

For teams evaluating whether to build auth flow automation in-house or use a no-code tool, Astaqc’s manual vs. automated testing guide covers when framework-based automation is justified and when a no-code approach reduces total cost. The outsourcing QA guide is relevant for teams that need OAuth flow coverage but lack the internal capacity to build and maintain it. Astaqc’s automation services and hire-a-team page cover how embedded QA coverage works for teams that need ongoing auth flow testing without building a dedicated automation function.

Frequently Asked Questions

Can TestInspector test OAuth flows where the IdP login page blocks automation tools?

Most IdPs do not block well-behaved browser automation. Google, Okta, and Azure AD may limit or require additional configuration for accounts accessed from automation clients, but dedicated test accounts with stable credentials typically work without triggering bot detection. For IdPs that do block browser automation on the login page, the HTTP step approach—posting credentials directly to the token endpoint if the IdP supports the Resource Owner Password Credentials grant, or bypassing the UI login by setting a session cookie or JWT from a previous HTTP-level auth call—can cover the token validation without going through the IdP’s UI.

How does TestInspector store TOTP secrets securely?

TOTP secrets are stored as encrypted variables in TestInspector’s variable system at the org, suite, or test level. The variable is encrypted at rest and is not visible in the test configuration UI after it is saved. It is resolved at execution time and written to the input field without being logged in the run output. The base32 secret itself is not recoverable from the TestInspector interface once stored, so teams should maintain an out-of-band backup of the secret if the test account’s TOTP needs to be reconfigured.

What happens if the TOTP code expires mid-test?

TestInspector resolves the {{TOTP:secret}} variable at the moment the step executes, not when the test starts. If the test reaches the TOTP input step within a new 30-second window, the generated code is valid for that window. TOTP codes have a brief grace period on most IdPs—the previous code remains valid for one additional window—which means a code generated at the boundary between two 30-second intervals is typically still accepted. In practice, test execution is fast enough that the code generated when the step executes is valid by the time the form submission reaches the IdP.

Can TestInspector validate token expiry and session timeout behavior?

Yes, through a combination of HTTP steps and scheduled runs. For testing token expiry, a test can use HTTP steps to make an authenticated API call immediately after login, then make the same call again after the token’s expiry period, and assert that the second call returns a 401 Unauthorized. For testing session timeout in the browser, TestInspector’s scheduling and wait step functionality supports a wait period between steps, though very long expiry periods (24 hours or more) are better validated with integration tests at the API level rather than through browser-based automation.

How should test accounts for OAuth testing be managed in a team environment?

Each test environment (dev, staging, production smoke) should have its own dedicated test account in the IdP. Test account credentials are stored as encrypted suite-level variables, so different suites can reference different accounts without the credentials appearing in the test steps. For teams with multiple QA engineers, TestInspector’s org-level variable scoping means shared test account credentials are set once at the org level and inherited by all tests that reference them, eliminating the need for each engineer to maintain their own credential copies. Access to org-level variable management is controlled by the owner and admin roles in TestInspector’s multi-tenant access model.