Skip to main content
Build your own credential collection UI instead of using the hosted page. Poll for login fields, then submit credentials via the API. Use the Programmatic flow when:
  • You need a custom credential collection UI that matches your app’s design
  • You’re building headless/automated authentication
  • You have credentials stored and want to authenticate without user interaction

How It Works

1

Create Connection and Start Session

Same as Hosted UI
2

Poll and Submit

Poll until flow_step becomes AWAITING_INPUT, then submit credentials
3

Handle 2FA

If more fields appear (2FA code), submit again—same loop handles it

Getting started

1. Create a Connection

A Managed Auth Connection associates a profile to a domain you want to keep authenticated so you can use the auth connection future browsers. Create one for each domain + profile combination you want to keep authenticated.
const auth = await kernel.auth.connections.create({
  domain: 'github.com',
  profile_name: 'github-profile', // Name of the profile to associate with the connection
});

2. Start a Login Session

const login = await kernel.auth.connections.login(auth.id);
Credentials are saved automatically on successful login, enabling automatic re-authentication when the session expires.

3. Poll and Submit Credentials

A single loop handles everything—initial login, 2FA, and completion:
let state = await kernel.auth.connections.retrieve(auth.id);

while (state.flow_status === 'IN_PROGRESS') {
  // Submit when fields are ready (login or 2FA)
  if (state.flow_step === 'AWAITING_INPUT' && state.discovered_fields?.length) {
    const fieldValues = getCredentialsForFields(state.discovered_fields);
    await kernel.auth.connections.submit(auth.id, { fields: fieldValues });
  }
  
  await new Promise(r => setTimeout(r, 2000));
  state = await kernel.auth.connections.retrieve(auth.id);
}

if (state.status === 'AUTHENTICATED') {
  console.log('Authentication successful!');
}
The discovered_fields array tells you what the login form needs:
// Example discovered_fields for login
[{ name: 'username', type: 'text' }, { name: 'password', type: 'password' }]

// Example discovered_fields for 2FA
[{ name: 'otp', type: 'code' }]

Complete Example

import Kernel from '@onkernel/sdk';

const kernel = new Kernel();

// Create connection
const auth = await kernel.auth.connections.create({
  domain: 'github.com',
  profile_name: 'github-profile',
});

const login = await kernel.auth.connections.login(auth.id);

// Single polling loop handles login + 2FA
let state = await kernel.auth.connections.retrieve(auth.id);

while (state.flow_status === 'IN_PROGRESS') {
  if (state.flow_step === 'AWAITING_INPUT' && state.discovered_fields?.length) {
    // Check what fields are needed
    const fieldNames = state.discovered_fields.map(f => f.name);
    
    if (fieldNames.includes('username')) {
      // Initial login
      await kernel.auth.connections.submit(auth.id, {
        fields: { username: 'my-username', password: 'my-password' }
      });
    } else {
      // 2FA or additional fields
      const code = await promptUserForCode();
      await kernel.auth.connections.submit(auth.id, {
        fields: { [state.discovered_fields[0].name]: code }
      });
    }
  }

  await new Promise(r => setTimeout(r, 2000));
  state = await kernel.auth.connections.retrieve(auth.id);
}

if (state.status === 'AUTHENTICATED') {
  console.log('Authentication successful!');
  
  const browser = await kernel.browsers.create({
    profile: { name: 'github-profile' },
    stealth: true,
  });
  
  // Navigate to the site—you're already logged in
  await page.goto('https://github.com');
}
This example covers username/password login with 2FA — the most common flow. If the site uses SSO, MFA selection, account pickers, or external actions (push notifications), see Handling Different Input Types below for how to handle each case.
Every programmatic login session also has a hosted_url. If your flow encounters an unexpected state, you can redirect the user to this URL to complete login via the Hosted UI instead.

Handling Different Input Types

The basic polling loop handles discovered_fields, but login pages can require other input types too.

SSO Buttons

When the login page has “Sign in with Google/GitHub/Microsoft” buttons, they appear in pending_sso_buttons:
if (state.pending_sso_buttons?.length) {
  // Show the user available SSO options
  for (const btn of state.pending_sso_buttons) {
    console.log(`${btn.provider}: ${btn.label}`);
  }
  
  // Submit the selected SSO button
  await kernel.auth.connections.submit(auth.id, {
    sso_button_selector: state.pending_sso_buttons[0].selector
  });
}
Common SSO provider domains (Google, Microsoft, Okta, Auth0, GitHub, etc.) are automatically allowed. For custom OAuth providers, add their domains to allowed_domains on the connection.

SSO Provider Selection

As an alternative to clicking an SSO button by selector, you can submit the SSO provider name directly. When SSO buttons are detected, the session state includes a sso_provider field (a string) identifying the provider that Kernel recommends. You can also specify a provider explicitly using the sso_provider submit parameter:
if (state.pending_sso_buttons?.length) {
  // Submit by provider name instead of selector
  await kernel.auth.connections.submit(auth.id, {
    sso_provider: state.pending_sso_buttons[0].provider  // e.g., "google"
  });
}
sso_provider is a singular string value, not an array. Use sso_button_selector when you need to click a specific button by its CSS selector, and sso_provider when you want to identify the provider by name (e.g., "google", "microsoft", "okta").

MFA Selection

When the site offers multiple MFA methods, they appear in mfa_options:
if (state.mfa_options?.length) {
  // Available types: sms, email, totp, push, call, security_key
  for (const opt of state.mfa_options) {
    console.log(`${opt.type}: ${opt.label}`);
  }

  // Submit the selected MFA method
  await kernel.auth.connections.submit(auth.id, {
    mfa_option_id: 'sms'
  });
}
After selecting an MFA method, the flow continues. Poll for discovered_fields to submit the code, or handle external actions for push/security key.

Sign-In Options (Account/Org Pickers)

Some sites present non-MFA choices during login, such as account selection or organization pickers. These appear in sign_in_options as an array of objects with id, label, and optional description:
if (state.sign_in_options?.length) {
  // Show available options to the user
  for (const opt of state.sign_in_options) {
    console.log(`${opt.id}: ${opt.label}`);
    if (opt.description) console.log(`  ${opt.description}`);
  }

  // Submit the selected option
  await kernel.auth.connections.submit(auth.id, {
    sign_in_option_id: state.sign_in_options[0].id
  });
}
Sign-in options are distinct from MFA options. MFA options (mfa_options) represent second-factor authentication methods like SMS or TOTP. Sign-in options represent non-security choices like “Which account do you want to use?” or “Select your organization.”

External Actions (Push, Security Key)

When the site requires an action outside the browser (push notification, security key tap), the step becomes AWAITING_EXTERNAL_ACTION:
if (state.flow_step === 'AWAITING_EXTERNAL_ACTION') {
  // Show the message to the user
  console.log(state.external_action_message);
  // e.g., "Check your phone for a push notification"
  
  // Keep polling—the flow resumes automatically when the user completes the action
}

Step Reference

The flow_step field indicates what the flow is waiting for:
StepDescription
DISCOVERINGFinding the login page and analyzing it
AWAITING_INPUTWaiting for field values, SSO button click, SSO provider selection, MFA selection, or sign-in option selection
SUBMITTINGProcessing submitted values
AWAITING_EXTERNAL_ACTIONWaiting for push approval, security key, etc.
COMPLETEDFlow has finished

Status Reference

The flow_status field indicates the current flow state:
StatusDescription
IN_PROGRESSAuthentication is ongoing—keep polling
SUCCESSLogin completed, profile saved
FAILEDLogin failed (check error_message)
EXPIREDFlow timed out (10 minutes for user input, 20 minutes overall)
CANCELEDFlow was canceled
The status field indicates the overall connection state:
StatusDescription
AUTHENTICATEDProfile is logged in and ready to use
NEEDS_AUTHProfile needs authentication

Updating Connections

After creating a connection, you can update its configuration with PATCH /auth/connections/{id}:
FieldDescription
login_urlOverride the login page URL
credentialUpdate the linked credential
allowed_domainsUpdate allowed redirect domains
health_check_intervalSeconds between health checks (minimum varies by plan)
save_credentialsWhether to save credentials on successful login
proxyProxy configuration for login sessions
Only the fields you include are updated—everything else stays the same.
await kernel.auth.connections.update(auth.id, {
  login_url: 'https://example.com/login',
  health_check_interval: 1800,
  save_credentials: true,
});

Real-Time Updates with SSE

For real-time UIs, you can stream login flow events via Server-Sent Events instead of polling:
GET /auth/connections/{id}/events
The stream delivers managed_auth_state events with the same fields as polling (flow_status, flow_step, discovered_fields, etc.) and terminates automatically when the flow reaches a terminal state.
Polling is recommended for most integrations. SSE is useful when building real-time UIs that need instant updates without polling delays.