- 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
Stream and Submit
Follow the connection’s SSE stream and submit credentials when
flow_step becomes AWAITING_INPUT3
Handle 2FA
If more fields appear (2FA code), submit again—same loop handles it
Getting started
1. Create a Connection
A Managed Auth Connection attaches an authenticated domain to a profile so you can use the auth connection in future browsers. A single profile can hold multiple auth connections — create one connection for each domain you want to keep authenticated on that profile.2. Start a Login Session
3. Stream and submit credentials
A single SSE stream handles everything—initial login, 2FA, and completion:discovered_fields array tells you what the login form needs:
Complete Example
Handling Different Input Types
The SSE event loop handlesdiscovered_fields, but login pages can require other input types too. In the examples below, state is the current managed_auth_state event from the stream.
SSO Buttons
When the login page has “Sign in with Google/GitHub/Microsoft” buttons, they appear inpending_sso_buttons:
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 asso_provider field (a string) identifying the provider that Kernel recommends. You can also specify a provider explicitly using the sso_provider submit parameter:
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 inmfa_options:
discovered_fields to submit the code, or handle external actions for push/security key.
The
switch type represents generic method-switcher links like “Use another method” or “Try another way” that don’t name a specific factor. Submit it the same way as any other MFA option to reveal the underlying alternatives on the next page.Sign-In Options (Account/Org Pickers)
Some sites present non-MFA choices during login, such as account selection or organization pickers. These appear insign_in_options as an array of objects with id, label, and optional description:
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 becomesAWAITING_EXTERNAL_ACTION:
mfa_options, pending_sso_buttons, and sign_in_options may be populated during AWAITING_EXTERNAL_ACTION when the site exposes fallback methods alongside the external action (for example, “Try another way” on a push prompt). Submit one of them to switch verification methods, or keep listening to let the user complete the external action.Step Reference
Theflow_step field indicates what the flow is waiting for:
Status Reference
Theflow_status field indicates the current flow state:
The
status field indicates the overall connection state:
Connection Configuration
Connection-level options — custom login URL, SSO/OAuth, custom proxy, session recording, post-login URL, and updates — apply equally to all integration flows and are documented in Connection Configuration.SSE stream behavior
auth.connections.follow() opens the Server-Sent Events stream at:
managed_auth_state events containing flow_status, flow_step, discovered_fields, and the other login-flow fields used throughout this guide. It closes automatically when the flow succeeds, fails, expires, or is canceled.
Use the SSE stream for login flows. It delivers state changes immediately and avoids repeated status requests.