Applications

An application (client) is the integration point between your software and Kenni. Each application has its own credentials, redirect URIs, branding, and feature configuration. You manage applications from the Applications section of the developer portal.

When you create an application, Kenni issues a client_id (prefixed with your team domain, e.g. @my-app.is/web) and — for confidential clients — a client_secret. These identify your application to the OIDC endpoints under https://idp.kenni.is/<team-domain>.

Application types

Pick the type that matches how your software talks to Kenni. The type controls which grants are available, whether a client_secret is issued, and which fields you can configure.

Type	Use for	Client secret	Grants
Web	Server-rendered apps and APIs that can keep a secret	Yes	authorization_code, refresh_token
Web (SPA)	Single-page apps running entirely in the browser	No	authorization_code (PKCE), refresh_token
Native	iOS, Android, and desktop apps	No	authorization_code (PKCE), refresh_token
Machine to Machine	Backend-to-backend integrations with no end user	Yes	client_credentials
Device	Smart TVs, CLI tools, and other input-constrained devices	No	urn:ietf:params:oauth:grant-type:device_code, refresh_token

Redirect URIs

Web, SPA, and Native applications must declare every URI Kenni is allowed to redirect the user back to after authentication. Anything not on the list is rejected. Add one URI per line in the application settings.

Machine-to-Machine and Device applications don't use redirect URIs — M2M obtains tokens directly from the token endpoint, and Device flows verify the user out-of-band via the activation page.

Client credentials

For confidential clients (Web and M2M), Kenni stores a hashed client_secret. The full secret is shown once when the application is created and is then masked. You can copy the masked value, but the only way to recover a lost secret is to rotate it from the application's Settings tab — which invalidates the old secret immediately.

Public clients (SPA, Native, Device) don't get a secret. They authenticate the user via PKCE (for code-flow clients) or the device verification step instead.

Endpoints

Each team has its own OIDC issuer at https://idp.kenni.is/<team-domain>. The standard endpoints are derived from it:

• Discovery — /.well-known/openid-configuration
• Authorization — /oidc/auth
• Token — /oidc/token
• Token introspection — /oidc/token/introspection
• User info — /oidc/me
• JWKS — /oidc/jwks

Device applications also expose:

• Device authorization — /oidc/device/auth
• Device verification — /activate

The exact URLs for an application are available on its Overview tab in the portal.

Next steps