- 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
Create Connection and Start Session
Same as Hosted UI
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.2. Start a Login Session
3. Poll and Submit Credentials
A single loop handles everything—initial login, 2FA, and completion:discovered_fields array tells you what the login form needs:
Complete Example
Handling Different Input Types
The basic polling loop handlesdiscovered_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 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.
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:
Step Reference
Theflow_step field indicates what the flow is waiting for:
| Step | Description |
|---|---|
DISCOVERING | Finding the login page and analyzing it |
AWAITING_INPUT | Waiting for field values, SSO button click, SSO provider selection, MFA selection, or sign-in option selection |
SUBMITTING | Processing submitted values |
AWAITING_EXTERNAL_ACTION | Waiting for push approval, security key, etc. |
COMPLETED | Flow has finished |
Status Reference
Theflow_status field indicates the current flow state:
| Status | Description |
|---|---|
IN_PROGRESS | Authentication is ongoing—keep polling |
SUCCESS | Login completed, profile saved |
FAILED | Login failed (check error_message) |
EXPIRED | Flow timed out (10 minutes for user input, 20 minutes overall) |
CANCELED | Flow was canceled |
status field indicates the overall connection state:
| Status | Description |
|---|---|
AUTHENTICATED | Profile is logged in and ready to use |
NEEDS_AUTH | Profile needs authentication |
Updating Connections
After creating a connection, you can update its configuration withPATCH /auth/connections/{id}:
| Field | Description |
|---|---|
login_url | Override the login page URL |
credential | Update the linked credential |
allowed_domains | Update allowed redirect domains |
health_check_interval | Seconds between health checks (minimum varies by plan) |
save_credentials | Whether to save credentials on successful login |
proxy | Proxy configuration for login sessions |
Real-Time Updates with SSE
For real-time UIs, you can stream login flow events via Server-Sent Events instead of polling: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.