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. these can support eligible automatic reauthentication attempts, including totp codes generated from an available secret. submitted one-time codes aren’t saved and don’t provide access to future codes. if a later login requires user input, your application must start a new interactive login. To opt out of credential saving, set save_credentials: false when creating the connection. credentials let you store login information securely. KERNEL can attempt automatic reauthentication for eligible flows using stored credentials, including totp codes generated from an available secret. saving credentials or completing an interactive login doesn’t guarantee unattended reauthentication. supplying a one-time code doesn’t give KERNEL the ability to obtain future codes. if a site requires user input, start a new interactive login. There are three ways to provide credentials:
  • Automatically save during login — Capture credentials directly from the user when they log in via Hosted UI or Programmatic
  • Pre-store in Kernel — Create credentials before login for supported headless authentication flows
  • Connect 1Password — Use credentials from your existing 1Password vaults

1Password Integration

Connect your 1Password vaults to automatically use existing credentials with Managed Auth. Credentials are automatically matched by domain.

Save credentials during login

By default, Kernel saves durable credential fields entered during login so they can be used for eligible reauthentication attempts. No extra parameters are needed:
Once saved, the browser profile reuses its authenticated session until the site expires it. For supported credential-based flows, Kernel can then reauthenticate with the stored values. Credentials are updated after every successful login. Submitted one-time codes aren’t saved; Kernel generates TOTP codes from a stored totp_secret. To opt out of credential saving, set save_credentials: false when creating the connection:

Pre-store credentials

For credential-based flows that you want to run without user input, create credentials upfront:
Then link the credential when creating a connection:

2FA with TOTP

For sites with authenticator app 2FA, include totp_secret so KERNEL can generate a fresh code during automatic login and reauthentication. Supply a base32 secret of 16–128 characters or an otpauth://totp/ provisioning URI. The default is SHA1, 6 digits, and a 30-second period. If the authenticator uses different settings, provide totp_algorithm (SHA1, SHA256, or SHA512), totp_digits (6–9), and totp_period (15–300 seconds):
The examples use typed fields available in TypeScript, Python, and Go SDK v0.116.0 or later. You can also pass an otpauth://totp/ provisioning URI as totp_secret.
  • URI parameters override explicit settings. If a parameter is missing, the API uses its explicit field, then the default.
  • Replacing a URI resets omitted settings to defaults. Rotating a raw secret preserves stored settings unless you send new values.
  • The API stores only the normalized seed, never the URI label or issuer.
  • A code’s length follows totp_digits; don’t assume six digits when reading totp_code or calling totpCode().

SSO / OAuth

For sites with “Sign in with Google/GitHub/Microsoft”, set sso_provider so Kernel can select the matching SSO route. Automatic completion depends on the provider’s login requirements. Common SSO provider domains (Google, Microsoft, Okta, Auth0, GitHub, etc.) are allowed by default, so you don’t need to add them to allowed_domains:

Partial credentials

Credentials don’t need to contain every field required by the login form. You can store what you have and collect the necessary fields from the user. auth.connections.login() pauses for missing values. As an example, the below credential has email + TOTP secret stored (and automatically handled), but no password. The password is dynamically collected from the user using Kernel’s Hosted UI or your Programmatic flow:
This is useful when you want to:
  • Store TOTP secrets but have users enter their password each time
  • Pre-fill username/email but collect password at runtime
  • Merge user-provided values into an existing credential automatically on successful login

Credential security

Credential notes

  • The values object is flexible and can be used to store whatever fields the login form needs (email, username, company_id, etc.)
  • Deleting a credential unlinks it from associated connections so they can no longer auto-authenticate
  • Use one credential per account. We recommend creating separate credentials for different user accounts

Automatic reauthentication

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 scheduled health check that confirms the session is logged out may trigger an eligible automatic reauthentication attempt. when false, expired sessions are marked NEEDS_AUTH without an automatic recovery attempt.
auto_reauth only has an effect on the automatic flow when health_checks is also true, because reauthentication requires a scheduled health check to confirm the session is logged out. an inconclusive check doesn’t trigger reauthentication. 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:

Browser region

Set browser.region to choose where Managed Auth runs the connection’s initial login, health checks, and automatic reauthentication. Choose from us-east, eu-west, and ap-southeast. Region selection is available on Start-Up and Enterprise plans; omitted values default to us-east.
Updating browser.region changes the connection default for browsers created afterward. It doesn’t move or restart an active login, health check, or reauthentication browser. You can override the connection region for one login without changing its default:
Browser placement and proxy location are independent. browser.region chooses where the browser runs; the connection’s proxy controls the exit IP that websites see. Regional browsers don’t provide a data residency guarantee. See Regional Browsers for storage and processing details.

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 proxies provide a static exit IP that persists across sessions, so the initial login, health checks, and reauths all exit through the same IP. The IP only changes in rare ISP-initiated replacement events or a temporary failover to a backup endpoint.
  • Datacenter proxies assign a new exit IP per request. Sites with adaptive auth that trigger a step-up challenge (one-time code, device verification) when the client IP changes may flag these IP shifts.
  • 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 pick one if the static IP must be infrastructure you control (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.