Get started
API scopes
Integration guides
Features
Troubleshooting
Prompts
The OIDC prompt parameter controls which interactions Kenni shows the user before completing the authorization request. The same application can drive completely different sign-in flows — fresh login, delegation picker, custom-delegation admin, passkey enrollment — by varying prompt per request.
Pass it as a space-separated list on the authorization endpoint:
GET /oidc/auth?prompt=login%20delegation&scope=openid%20display_name&...
Kenni evaluates the prompts in policy order (regardless of how you ordered them in the query string), shows each screen as it becomes due, and finishes by redirecting to your redirect_uri once every prompt has been resolved.
Standard prompts
These come from the OIDC spec.
| Prompt | Effect |
|---|---|
none | Never show UI. If a valid session exists the request completes silently; otherwise it fails with login_required. Use this to probe for an active SSO session without disturbing the user. |
login | Force a fresh authentication even when SSO would otherwise let the user through silently. Useful right after a local logout to make "Sign out" feel real. |
consent | Re-display the consent screen for the requested scopes, even if the user has already granted them on a previous visit. Useful when you need an explicit re-confirmation. |
select_account is not supported — Kenni only ever has one signed-in account per browser.
Kenni-specific prompts
Three prompts are Kenni extensions. They're requestable: they only run when explicitly named on the request, so an application can choose between "sign in as self" and "sign in as a company" by toggling prompt=delegation.
delegation
Shows the delegation picker. The user picks the company or custom delegation they want to act for, and the resulting token has the delegation as the subject with the actor's identity nested under actor.*.
GET /oidc/auth?prompt=delegation&scope=openid%20company_name&...
Both company delegations and custom delegations appear in the picker — Kenni filters to the types the application has allowed.
Requires company delegations or custom delegations to be enabled on your team's plan. Without either, the request fails.
delegation_admin
Shows the custom-delegation admin screen — Kenni's "manage delegates" UI for the application's custom delegation types. The user adds or removes other people as delegates of the types your team defined.
GET /oidc/auth?prompt=delegation_admin&...
Typically wired to a "Manage access" button in your application's settings.
Requires custom delegations to be enabled on your team's plan.
credential
Opens Kenni's passkey-management screen for the signed-in user. From here the user can enroll a new passkey and view or delete existing ones — every passkey across every device they've registered against Kenni, in one place.
GET /oidc/auth?prompt=credential&...
Most applications never need to set this explicitly — Kenni offers passkey enrollment automatically after a successful login unless skipping passkeys is enabled. The cases where prompt=credential is useful:
- Self-service passkey management. A "Manage your passkeys" link in your application's settings sends the user to Kenni to add a new device or remove an old one. Cleaner than building your own UI on top of the API.
- Removing a credential the user no longer recognises. If a user reports a lost device, a phone they no longer own, or a passkey they don't remember enrolling, point them at this screen so they can delete it themselves. Kenni revokes the credential immediately.
- Testing your integration. During development, deleting your test user's passkeys is the fastest way to drive the enrollment flow again on the next sign-in.
Chaining prompts
prompt accepts multiple values. Kenni runs each prompt in policy order and only redirects back to your application once every screen has been resolved. The order is fixed — listing them in a different order in the query string doesn't change the order they appear in the UI.
| Combination | What the user sees |
|---|---|
login delegation | Authenticate, then pick a delegation. Skips SSO even if a session exists. |
login delegation delegation_admin | Authenticate, pick a delegation, then land on the delegation admin screen for the resulting subject. |
delegation consent | Pick a delegation, then re-confirm consent for the delegated scopes. |
delegation delegation_admin | Pick a delegation, then manage delegates for the chosen subject — common pattern for "act as company, then admin". |
none | Silent. Either completes immediately or fails with login_required / consent_required / interaction_required. |
Chaining is the right tool when one user action needs more than one screen — e.g. an admin who taps "Manage company access" should authenticate, pick the company, and land on the delegation admin in one continuous flow.
The test app ships a UI that lets you fire any of these combinations against a configured client. It's the fastest way to see how the chained flows feel.
Per-call prompt in framework guides
Several frameworks make it tricky to vary prompt per click — the parameter has to be passed through the library to the authorization request:
- Next.js / better-auth — pass
additionalData: { prompt: "delegation" }onsignIn.oauth2, and read it back inauthorizationUrlParams. - Expo —
extraParams: { prompt: "login" }onuseAuthRequest. - Flutter —
promptValues: ['login']onAuthorizationTokenRequest. - Spring Boot — pass
promptviaOAuth2AuthorizationRequestCustomizers.
Where the library doesn't have an obvious slot for it, the simplest answer is to register the same client a second time with a different providerId and a static prompt configured — but the per-call pattern above is cleaner where it's available.