Skip to main content
Managed Auth connections use the same configuration whether you collect credentials through the Hosted UI, the React component, or the programmatic flow. These options apply to the initial login, every background health check, and each automatic reauthentication attempt.

Credentials and Auto-Reauth

By default, Kernel saves durable credential fields after a successful login. Kernel can automatically reauthenticate credential-only flows and attempts to provide TOTP codes when needed. Submitted one-time codes (TOTP, SMS, etc.) aren’t saved. To opt out of credential saving, set save_credentials: false when creating the connection. See Credentials for configuration examples. Automatic re-authentication is gated by two boolean flags that both default to true:
  • health_checks — whether the connection runs periodic health checks at all. When false, the system never automatically verifies the session and never triggers reauth on its own.
  • auto_reauth — whether a failed scheduled health check is allowed to attempt re-authentication. When false, expired sessions are marked NEEDS_AUTH instead of being repaired automatically.
auto_reauth only has an effect on the automatic flow when health_checks is also true, because reauth is triggered by a failing scheduled health check. Manually triggering a health check via the API still works regardless of health_checks.
Both flags can be flipped on an existing connection with auth.connections.update; changes take effect immediately on the running connection. Automatic reauthentication requires a previously successful login and saved credentials for the durable login fields. Setting auto_reauth: true permits Kernel to attempt it but doesn’t guarantee the next login will succeed. If Kernel can’t complete an automatic attempt, the connection transitions to NEEDS_AUTH so you can start a new login.

Custom Login URL

If the site’s login page isn’t at the default location, specify it when creating the connection:

SSO/OAuth Support

Managed Auth supports common “Sign in with Google/GitHub/Microsoft” flows. The user completes the OAuth flow with the provider, and Kernel saves the authenticated session to the profile. Automatic reauthentication depends on the provider’s login requirements. See Can this connection auto-reauth? for how Kernel determines eligibility. Common SSO provider domains are automatically allowed by default, including Google, Microsoft/Azure AD, Okta, Auth0, Apple, GitHub, Facebook, LinkedIn, Amazon Cognito, OneLogin, and Ping Identity. You don’t need to add these to allowed_domains. For custom or less common OAuth providers, add their domains to allowed_domains:

Custom Proxy

Pin the auth flow to a specific proxy so logins, health checks, and automatic re-authentications all egress through that proxy. This is useful for sites that allowlist IPs, geo-pin sessions, or treat IP changes as a fraud signal. How stable the exit IP is depends on the proxy type:
  • ISP and datacenter proxies provide a stable exit IP within a single session, but Kernel does not guarantee the same IP across sessions. Sites with adaptive auth that trigger a step-up challenge (one-time code, device verification) when the client IP changes may flag the IP shift between the initial login and a subsequent health check or reauth.
  • Residential proxies rotate IPs per connection — use them when you need legitimacy from a real ISP pool but can tolerate IP changes.
  • Custom (BYO) proxies route through whatever you point them at, so this is the right pick if you need a truly static IP that persists across the initial login and every subsequent health check and reauth (e.g. an allowlisted egress your security team owns).
Create a proxy first, then attach it to the connection:
You can also reference a proxy by name instead of id. The proxy must belong to the same org and project as the connection. Once attached, every browser the connection spins up — the initial login, every background health check, and every automatic re-auth — runs through that proxy. You can swap the proxy on an existing connection with auth.connections.update; the change takes effect immediately, so the next health check or reauth uses the new proxy.
You can also override the connection’s proxy for a single login by passing proxy on .login() — useful when you want to try a one-off egress without changing the connection-wide default (which would also affect subsequent health checks and reauths).

Record Sessions for Debugging

Set record_session: true to capture a replay of every browser session tied to the connection — initial logins, background health checks, and automatic re-authentications. The entire browser session is recorded.
You can also override the connection default for a single login by passing record_session on .login() — useful for one-off debugging on a specific login attempt without flipping the connection-wide flag (which would also record subsequent health checks and reauths).
Managed auth recordings are subject to the same retention rules as other session replay recordings. Each managed auth session row stores its own replay_id for the recording captured during that session.

Post-Login URL

After successful authentication, post_login_url will be set to the page where the login landed. Use this to start your automation from the right place:

Updating a Connection

After creating a connection, you can update its configuration with auth.connections.update: Only the fields you include are updated—everything else stays the same. Changes to health_check_interval, health_checks, auto_reauth, and proxy take effect immediately on the running connection.