Company delegations

A company delegation lets an authenticated person sign into your application as a legal entity they have authority over. The user authenticates as themselves, picks the company they want to act for, and your application receives a token whose subject is the company — with the actor's identity nested under actor.*.

The list of who can act for which company is sourced from the Icelandic company registry. Kenni surfaces these relationships during login; your application doesn't have to model them.

Plan setup

Company delegations are gated by your plan tier. When supported, the Delegations tab on each application in the developer portal lets you configure which delegation types are accepted.

Delegation types

The company registry tracks several kinds of authority a person can hold over a company. Kenni exposes them as named delegation types:

Common types
c:procurator	Procurator
c:ceo	Chief Executive Officer
c:board	Board member
c:auditor	Auditor

Uncommon types
c:owner	Owner
c:founder	Founder
c:agent	Agent
c:branch-manager	Branch manager
c:vice-board	Vice board

Pick the types your application is willing to accept on the application's Delegations tab. A user who only holds excluded types won't see the company in the delegation picker.

The uncommon types are kept behind a collapsible because the company registry rarely populates them — most users will only ever appear as procurators, CEOs, or board members.

Self-delegation

The same tab has a Support self-delegation toggle. When on, the delegation picker offers "Sign in as yourself" alongside the list of companies. When off, the user must choose a company to proceed — useful for back-office tools that are only meant for company use.

If the user holds no company delegations and self-delegation is off, the authorization request fails with access_denied.

Triggering the delegation prompt

The delegation picker is requestable — it only appears when the authorization request includes prompt=delegation:

GET /oidc/auth?prompt=delegation&scope=openid%20company_name&...

Without the prompt, the user signs in as themselves and the delegation picker is skipped entirely. This means the same application can support both self-login and company-delegated login depending on the request — typically a "Sign in as company" button that adds prompt=delegation to the request.

Claims released for a delegated session

In a delegated session, two identities are present:

• The subject (root claims) — the company. Kenni releases the company_* scopes here: company_name from the registry (auto-consent), and company_display_name, company_email, company_phone_number, company_logo from the team's profile (require consent).
• The actor (actor.* claims) — the person signed in. Released by the actor_* scope family: actor_audkenni_name, actor_audkenni_phone_number, actor_national_id (auto-consent), and actor_display_name, actor_picture, actor_phone_number, actor_email (require consent).

The full claim shape is documented on Scopes and claims. The per-scope reference table is on Standard scopes.

A delegation_type claim is always included in a delegated session — an array listing the delegation types the actor holds for this subject. Useful for authorization decisions on your side: e.g. only accept c:procurator or c:ceo for high-impact actions.

Next steps