Can a Browser Monitor Sign In With OAuth, SSO, or a Passkey?

Short answer: No. A form-fill browser login monitor cannot complete an OAuth redirect, a SAML or OIDC SSO bounce, a passkey ceremony, an MFA challenge, or a magic link. Stop trying to make it. Monitor the identity provider's token endpoint with a multi-step API monitor, assert one protected route with the access token, and expose a small canary route in your own app that an HTTP monitor can poll. That combination catches Entra and Okta outages in under five minutes. If your login actually is email and password on your own domain, the browser login monitor is the right tool and we already wrote that post: see how to monitor a SaaS login that IS email and password. This post is the sibling for everything else. Built for SaaS application monitoring teams whose login is anything but a single form. Start for free.

Microsoft 365 lost SSO and MFA on October 8, 2025. Status-only monitors stayed green.

On October 8, 2025, Microsoft posted incident MO1168102 against Microsoft 365. The impact list named Microsoft Teams, Exchange Online, the Microsoft 365 admin center, Microsoft Entra SSO authentication, and MFA. Microsoft's own root-cause language was "a portion of directory operations infrastructure which became imbalanced during a period of high traffic volume and caused authorization failures" (BleepingComputer coverage, MO1168102). Translation: the part of Entra that issues authorization decisions stopped issuing them, while everything else looked fine from the outside.

Status-only monitors pointed at portal.office.com kept returning 200 OK while the IdP path was failing. The portal HTML rendered. The marketing chrome loaded. The CSS came back. Real users hit sign-in and got error pages, because Entra refused to issue a token they could use. Every team whose monitoring stopped at "the host answered" learned the same lesson at the same time. This is the same defect class we walk through in five outage classes standard monitoring misses.

The honest defense against an IdP-flavored outage is not a better form-fill primitive. It is monitoring the identity provider as a third-party dependency you do not own (we cover the broader pattern in treat your IdP as a third-party dependency), plus a canary route in your app that says out loud whether authentication just round-tripped. Both are cheap. Both are unambiguous. Neither is a form-fill browser monitor.

What a browser login monitor actually drives

Velprove's browser login monitor is a form-fill primitive. Every browser login monitor has exactly one loginUrl, exactly two credentials stored in check_secrets (BROWSER_USERNAME and BROWSER_PASSWORD), three optional CSS selectors for the username field, the password field, and the submit button (auto-detected when blank), and one successIndicator chosen from url_pattern, text_present, or selector_visible. That is the entire shape.

Every check loads the URL, locates the two fields, types the credentials, clicks submit, waits for navigation, and checks the success indicator against the rendered DOM. That is exactly what a real customer signing in with email and password looks like, which is why it works for that case. It is also why it fails for everything else: there is no second URL, no token capture, no third-party redirect handling, no second factor input, no authenticator integration, no inbox reader.

Velprove ships four monitor types in total: Browser login, HTTP, API, and Multi-step API. When the login flow is not a single form, the work moves out of the browser primitive and into the multi-step API plus HTTP primitives. The rest of this post is the recipe for that move.

Five login patterns a form-fill browser monitor cannot drive

Five common login patterns push the work outside what a form-fill primitive can do. The honest answer in each case is the same: do not bend the browser monitor into the wrong shape. Use the right primitive for the actual auth flow.

Pattern 1: OAuth redirect (authorization code flow)

OAuth's authorization code flow (OAuth 2.0 spec) bounces the user to a third-party authorization server, asks for consent, redirects back with a code, and exchanges the code for an access token at the token endpoint. The browser login monitor has one loginUrl; it cannot follow the bounce to the provider, click the consent button, and ride the redirect back with the code in the query string.

Right primitive: a multi-step API monitor against the token endpoint using client_credentials for service-to-service cases, or refresh_token for a long-lived refresh token you minted out of band for the synthetic test identity. The browser chrome is not what is interesting; the token round trip is.

Pattern 2: SSO via SAML or OIDC IdP

SAML 2.0 (SAML 2.0) bounces the user from the service provider to the identity provider, posts a signed assertion back, and ends with a session in the SP. OpenID Connect (OpenID Connect) is the modern equivalent over OAuth. Neither survives a single form fill. SAML ECP (Enhanced Client or Proxy) exists, but it requires the IdP to enable an ECP profile, which most enterprise deployments deliberately disable. Do not assume ECP. Do not pitch ECP to a customer who has not turned it on.

Right primitive: OIDC client_credentialsagainst the IdP's token endpoint, plus a canary route in your app that proves the SP-side session check still works.

Pattern 3: Passkey or WebAuthn

WebAuthn (W3C WebAuthn Level 2) requires a real authenticator: a hardware security key, a phone biometric, or a platform credential signed by the OS. Chrome DevTools and Playwright support a virtual authenticator for testing an app you control. Velprove's browser login monitor primitive does not wire up a virtual authenticator. Do not assume it does.

Right primitive: monitor the IdP's OIDC discovery endpoint and token endpoint with HTTP and multi-step API monitors. Reserve the browser login monitor for the email-and-password flow on your own login page.

Pattern 4: MFA challenge (TOTP, push, SMS)

Time-based one-time passwords need a shared secret and a clock. A push notification needs a phone and a human. An SMS needs a carrier path Velprove will not touch. None of these fit into the single-form-fill shape. Provision a synthetic test identity with MFA disabled and the lowest scope you can grant. Monitor the IdP and the protected route, not the human ceremony.

Pattern 5: Magic link

Magic-link sign-in posts an email to a server, the server emails a token, the user clicks the token, the server creates a session. Velprove does not read inboxes. The honest workaround is to assert the issuance call returns 200 with a multi-step API monitor, then assert a protected-route response using a token your app generates server-side for the synthetic test identity. If the link generator falls over, the issuance call fails. If the session backend falls over, the protected route fails. Two signals, no inbox required.

The workaround pattern: monitor the auth API, then assert the canary route

Seven steps inside this section, plus an eighth in the conclusion. About twenty minutes of work the first time, five minutes for each subsequent app. The HowTo schema embedded in this page mirrors the steps below verbatim.

Pick the right primitive: browser, multi-step API, or HTTP

Velprove has four monitor types: Browser login, HTTP, API, and Multi-step API. Pick the browser login monitor only when your sign-in page is a real email-and-password form on your own domain (see the sibling post for that recipe). For OAuth, SAML, passkey, MFA, or magic-link auth, the browser primitive is the wrong tool. Reach for the multi-step API monitor first, plus an HTTP monitor for the canary route. We unpack the choice in detail in the seven-question decision tree on browser vs HTTP.

Provision a dedicated test identity (no MFA, lowest scope)

Create a synthetic user in your identity provider. Smallest scope you can grant. MFA disabled (because the monitor cannot complete it). No real customer data behind it. No admin permissions. If the credentials leak, the blast radius is one inert account that can read nothing interesting. The safest approach is always a purpose-built test identity, never a real admin or a real customer.

Store credentials in Velprove's encrypted fields

Velprove encrypts the multi-step monitor's request body and headers at rest. Paste the client_id, client_secret, username, password, or refresh_token directly into the body or header fields of the multi-step monitor; the worker decrypts the request server-side before issuing it to your IdP. Browser login monitors use a dedicated check_secrets store keyed by name (BROWSER_USERNAME and BROWSER_PASSWORD) for the same encryption guarantee with a different shape. Plaintext secrets never sit in the database.

Build the multi-step API monitor against the token-grant endpoint

Step 1 of the multi-step monitor POSTs to your IdP's token endpoint with the grant your test identity is configured for. For service-to-service, the right grant is client_credentials. For an offline-issued user token, use refresh_token. ROPC is the last resort and we unpack why in the next H2. Assert status_code is 200 and json_path on $.access_token is present. This is exactly the pattern we unpack in multi-step API monitoring with a token-grant first step. Velprove's multi-step API monitor exposes exactly six assertion types: status_code, body_contains, body_not_contains, json_path, response_time_ms, and header_contains. Each step runs once. There is no polling, no retry-until, no wait-for-condition, no "within N seconds" freshness primitive. Snapshot per interval, asserted against the response body the IdP just sent.

Extract the access token and call one protected route

Step 2 of the multi-step monitor uses the access token captured from step 1 as a Bearer header on the Authorization request header, and calls one protected API route that exercises real authentication. Assert status_code is 200 and body_containsa value only an authenticated caller can see (your synthetic identity's email, a known role name, an account ID). This is the assertion that proves the IdP issued a token your API actually accepted, not just that the IdP returned a JSON blob. This pattern works equally well for API uptime monitoring for OAuth-protected endpoints where the API itself is the surface you care about.

Ship a /healthz/authed canary route in your own app

The multi-step monitor proves the IdP is up and the token round trip works from outside. The canary route proves the same thing from inside your own app, which is the perspective that matches your real customers' experience. Add an unauthenticated endpoint, conventionally /healthz/authed, that does the real work server-side: take a server-held service-account credential, exchange it for a token against the IdP, call one internal protected handler, and return 200 if the round trip succeeded or 503 if any step failed. The route is unauthenticated from the outside (no secrets sent over the wire) but its 200 is a real signal. We unpack the broader pattern in expose an unauthenticated /healthz that proxies the auth state.

Point a Velprove HTTP monitor at the canary route

Add a Velprove HTTP monitor that GETs /healthz/authed and asserts status_code is 200 plus a body_contains string the route returns when the auth round trip succeeded (the literal string "auth: ok" is plenty; anything stable and non-blank works). This is the second pair of eyes that catches IdP outages your multi-step monitor cannot reach, because the outage is between your app server and the IdP, not between the Velprove worker and the IdP.

If your app uses Clerk: the +clerk_test pattern

If your app uses Clerk, this is the cleanest pattern. Clerk supports a deterministic test-mode flow that fits Velprove's browser login primitive exactly. Per Clerk's testing documentation (test emails and phones): "Any email with the +clerk_test subaddress is a test email address. No emails will be sent, and they can be verified with the code 424242."

Provision one synthetic test user with an email like monitor+clerk_test@yourapp.com. Point a Velprove browser login monitor at your Clerk-hosted sign-in URL. The username field gets the +clerk_test email; the password field gets the fixed verification code 424242. Choose a text_presentsuccess indicator that only renders for signed-in users (a known piece of dashboard chrome, the user's name in the navbar, a logout button). The monitor runs every fifteen minutes from the region of your choice on the free plan.

One caveat directly from Clerk's documentation: "Every development instance has test mode enabled by default. If you need to use test mode on a production instance, you can enable it in the Clerk Dashboard. However, this is highly discouraged." Translation: prefer pointing this monitor at a staging environment, not at production. Production stays clean; the staging monitor proves the auth path works end to end. We are documenting the pattern, not shipping a case study; if you want a worked staging-environment example, the Clerk docs page above is the canonical source.

OAuth-protected APIs: client credentials grant is your friend, ROPC is the last resort

Two grants matter for monitoring an OAuth-protected API. Pick the first one you can.

OAuth 2.0 client_credentials grant. Designed for service-to-service auth. No user in the loop. You exchange a client_id and client_secret for an access token. Store both in Velprove check secrets. The monitor never touches a real user account. This is the right grant for almost every Velprove multi-step API monitor that authenticates against an IdP.

Resource Owner Password Credentials (ROPC) grant. The user's username and password go straight to the token endpoint. Older, simpler, and actively discouraged by every modern IdP. Microsoft's own documentation on the Entra ROPC flow (Microsoft Entra ROPC documentation) is unusually direct:

"Microsoft recommends you do notuse the ROPC flow; it's incompatible with multifactor authentication (MFA). In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks that aren't present in other flows. You should only use this flow when more secure flows aren't viable."

"As MFA becomes more prevalent, some Microsoft web APIs will only accept access tokens if they have passed MFA requirements. Applications and test rigs relying on ROPC will be locked out."

That second paragraph is the one that matters for monitoring. As more Microsoft APIs gate on MFA-enforced tokens, an Entra ROPC monitor will quietly stop working when the API behind it tightens its conditional access policy. Plan for ROPC to be a temporary workaround, not a long-term monitoring strategy on Entra.

Other IdPs land in different places. Amazon Cognito supports username-and-password auth via ADMIN_USER_PASSWORD_AUTH on the admin API (note: the modern flow is ADMIN_USER_PASSWORD_AUTH, not the older ADMIN_NO_SRP_AUTH). Google has no public ROPG-equivalent on its OAuth endpoints; service accounts plus the client_credentials grant against a Google Workspace domain is the supported path. Auth0 supports ROPC behind a tenant setting that is off by default. Okta supports the resource-owner password flow on tenants that explicitly enable it. In every case, the recommended order is the same: try client_credentials first, fall back to refresh_token with a long-lived refresh token minted out of band, and only reach for ROPC when both of those are unavailable.

When to use HTTP or multi-step API instead of a browser login monitor

Three short questions decide it. The honest decision rubric, in order:

1. Is your sign-in page an email-and-password form on a URL you own? If yes, use a browser login monitor. That is exactly its shape and it will catch the post-200-OK assertion failures status-only checks miss. We covered this case in the sibling post on monitor a SaaS login that IS email and password.
2. Is your sign-in a redirect to a third-party IdP, a passkey ceremony, an MFA challenge, or a magic link? If yes, the browser login monitor is the wrong primitive. Use a multi-step API monitor against the IdP's token endpoint plus an HTTP monitor against an unauthenticated canary route in your own app.
3. Is your API the surface you actually care about? If yes, skip the browser layer entirely. A multi-step API monitor that does client_credentials against the IdP and calls one protected route covers the case in two steps.

We unpack the full version of this rubric, with the seven branches that matter, in the seven-question decision tree on browser vs HTTP. The short version above is enough for ninety percent of the choices teams actually face.

Monitor the IdP as a third-party dependency

Once you accept that Entra, Okta, Auth0, Clerk, or Google is on the critical path for your sign-in, the right framing is to treat your IdP as a third-party dependency and monitor it the way you monitor any other vendor in your request path. Two endpoints carry most of the signal.

The OpenID Connect discovery endpoint, conventionally /.well-known/openid-configuration, is a public JSON document every OIDC IdP exposes. Velprove can hit it with an HTTP monitor, assert status_code 200 and body_contains on the literal "token_endpoint" field name, and you have a no-credentials smoke test that the IdP is reachable and serving configuration. The token endpoint itself, exercised by the multi-step monitor described above, is the second signal. When Entra MO1168102 reproduced in October 2025, the discovery endpoint kept responding while the token endpoint returned authorization failures. Two monitors, one signal each, no overlap.

Frequently asked questions

Can Velprove's browser login monitor complete an OAuth redirect to Google or Microsoft?

No. Velprove's browser login monitor is a form-fill primitive. It loads one login URL, types a username and a password into two fields, clicks a submit button, and asserts one of three success indicators (a URL pattern, a piece of text, or a CSS selector). It cannot follow an OAuth redirect to a third-party identity provider, handle the consent screen, or complete the authorization code exchange. Use the multi-step API monitor against the IdP's token endpoint instead, plus an unauthenticated canary route in your own app.

Can a browser login monitor sign in via SAML SSO or Okta?

No. SAML SSO bounces the user through the identity provider, posts a signed assertion back to the service provider, and ends with a session in the SP. A form-fill browser monitor with one loginUrl and two credential fields cannot drive that bounce chain. The clean workaround is OIDC client_credentialsagainst the IdP's token endpoint plus a canary route in your app that exercises the SP-side session check.

What about passkey or WebAuthn login?

No. WebAuthn requires a real authenticator (a security key, a phone biometric, or a platform credential). A form-fill browser monitor has no authenticator attached and no way to attach a virtual one in this primitive. Monitor the IdP's discovery and token endpoints with HTTP and multi-step API monitors instead. Reserve browser login monitors for the email-and-password flow on your own login page.

Does Velprove handle TOTP, push, or SMS MFA?

No. The browser login monitor has one login URL, two credentials, and three optional selectors. It cannot read a TOTP code from an authenticator app, approve a push notification on a phone, or receive an SMS. Use a dedicated synthetic test identity with MFA disabled and the lowest scope you can grant. Monitor the IdP and the protected route, not the human MFA ceremony.

How do I monitor a Clerk-protected app?

If your app uses Clerk, the cleanest pattern is the +clerk_testsubaddress in development mode. Clerk's documentation states that any email with the +clerk_test subaddress is a test email address, no emails are sent, and they can be verified with the code 424242. Create a synthetic test user with a +clerk_test email, point a Velprove browser login monitor at your Clerk-hosted sign-in page, fill the email and the fixed 424242 verification code, and assert a post-login element. Clerk also notes that test mode is highly discouraged on production instances, so prefer running this pattern against a staging environment.

What about magic-link login?

No. Magic-link auth requires reading an email inbox to extract the token, which Velprove does not do. The workaround is the same as for SSO: monitor the magic-link issuance endpoint with a multi-step API monitor that asserts the issuance call returns 200, then assert the protected-route response with a token your app generates server-side for the synthetic test identity. If the magic-link generator falls over, the issuance call fails. If the session backend falls over, the protected route fails.

Is the canary-route workaround a real monitor or a hack?

It is a real monitor and it is also a pattern your own application code controls. A /healthz/authed route exposed by your app that round-trips against your IdP using a server-side service account is a defensible signal: if the route returns 200 the auth backend is reachable and a token round trip just worked; if the route returns 503 something on the auth path broke. Velprove polls the route with an HTTP monitor and asserts the body. The route does the real auth work in your own infrastructure where you can keep secrets and run logic.

How do I monitor an OAuth-protected API without exposing user credentials?

Use the OAuth 2.0 client_credentials grant if your API supports it. The grant is designed for service-to-service auth: you exchange a client_id and client_secret for an access token with no user in the loop. Store both in Velprove check_secrets, build a multi-step API monitor where step 1 fetches the token and step 2 calls a protected route with the Bearer header, and you have a credential-free monitor that does not touch a real user account. If client_credentials is not available, the Resource Owner Password Credentials grant works but Microsoft and most modern IdPs actively discourage it.

Where this connects

Login is the single most expensive blind spot in commercial monitoring, and it splits cleanly in two. If your sign-in is a real email-and-password form on a URL you own, the browser login monitor is the right primitive and we wrote the recipe in monitor a SaaS login that IS email and password. If your sign-in is anything else (OAuth, SAML SSO, OIDC, passkey, MFA, magic link), the browser primitive is the wrong tool and the workaround above is the right one: multi-step API monitor against the IdP token endpoint, HTTP monitor against an unauthenticated canary route in your own app, both signed by a synthetic test identity that lives behind nothing.

Wire the alert to the channel that wakes the right person

Velprove ships email alerts on every plan including free. Slack, Discord, Teams, and outbound webhooks unlock on Starter. PagerDuty unlocks on Pro. Pick the channel the on-call actually reads. An alert that lands in a muted Slack channel is worse than no alert, because it teaches the team to trust the silence.

Free plan, your choice of five regions, browser login monitor every fifteen minutes, multi-step API and HTTP monitors at five-minute minimums, commercial use explicitly allowed, no credit card. Start for free. Monitor the login your customers actually use. If your stack is SaaS-shaped, the SaaS application monitoring page is the right next read; if the surface you care about is an OAuth-protected API, API uptime monitoring for OAuth-protected endpoints covers the same pattern from the API side.