Get started

Overview
Get started

Applications

Overview
Settings
Theming

API scopes

Overview
Standard scopes

Integration guides

No framework (curl)
Next.js / better-auth
React (SPA)
Expo (React Native)
Flutter
Node.js / Express
Java / Spring Boot
C# / .NET MVC
Go
Python
Other frameworks

Features

Scopes and claims
Prompts
Test users
Single sign-on
Company delegations
Custom delegations
Consent
Skipping passkeys
Device code flow

Troubleshooting

Common issues

Consent

Some identity scopes — display_name, email, the editable phone_number, the user's picture — release information the user has chosen to share with Kenni. Before your application can receive those claims, the user has to agree to share them with you specifically. The consent screen is where that agreement happens.

Auto-consent scopes (openid, national_id, audkenni_name, …) skip the consent screen entirely; their claims release the moment the user authenticates. The full split is on Scopes and claims.

Consent is a paid feature on a higher plan tier. Get in touch and we'll talk you through pricing and enable it for your team.

Plan and application setup

Consent is gated at two levels:

  1. Plan tier. Your team's plan must support consent. If it doesn't, the Consent tab on each application is hidden and the API rejects attempts to enable it.
  2. Per application. Each application that needs consent has to opt in. Open the application's Consent tab in the developer portal and tick Enable consent.

When consent is off on an application, requesting a non-auto-consent scope is a silent no-op — the request still succeeds, but the claim is not released and the user is never prompted.

Required scopes

The same Consent tab has a Required scopes list. Tick the scopes whose absence should block sign-in entirely:

  • A user who agrees to all required scopes proceeds normally.
  • A user who declines a required scope is bounced back to your application with access_denied instead of completing the flow.

Use this for scopes your application genuinely cannot work without (e.g. email for an app that only uses email as the account identifier). Leave it empty for scopes that are nice-to-have — the user will still see them on the consent screen and can choose to share them, but declining won't break the flow.

What the user sees

On first sign-in to an application with consent enabled, Kenni shows a screen listing every non-auto-consent scope the application is requesting, with the human-readable description for each. The user can:

  • Approve everything (the default action).
  • Decline individual optional scopes — those claims are not released, but the flow continues.
  • Decline a required scope — the flow aborts with access_denied.

Kenni remembers the decision per application. The next time the user signs in to the same application, the consent screen is skipped unless your application requests a scope they haven't seen before. If you start asking for a new scope, every previously-consented user gets re-prompted only for the new one.

Subject-type filtering

The consent screen is aware of who the user is signing in as. A request that includes both email (individual) and company_email (company) only shows the relevant scope:

  • For an individual sign-in: only email appears.
  • For a company-delegated sign-in: only company_email appears.

The same scope list can therefore be reused for both flows without your application having to special-case.

Consent in a delegated session is given as the delegate. The actor sees the consent screen for the scopes being released about themselves (the actor_* family) and about the subject they're acting for (company_*, the subject's identity scopes, …). Kenni records the consent against the actor's account so the next time they sign in for the same subject the screen is skipped.

If a different actor signs in for the same subject, they go through consent themselves — one user's consent doesn't grant on behalf of another.

Next steps