Built on two services, one identity

User access tokens

Every request is authenticated with a KivuNext ID access token — a signed JWT verified against the published JWKS. Tokens carry the user id, role and status, so the services, not the client, decide what a caller may do.

curl -H "Authorization: Bearer <access token>" \
  "$HUB_API_URL/applications/me"

This app never exposes the token to the browser: pages read it from the httpOnly cookie and call the services through the route handlers under /api/*.

Roles

• shield_personmember — apply, join cohorts, book mentors, post in channels.
• admin_panel_settingsstaff — additionally reviews applications, creates cohorts and opens org-wide analytics.
• keysuper_admin — staff permissions plus administrative configuration.

Guards are enforced in the services; a hidden button in this UI is never the security boundary.

API keys and webhooks

Server-to-server keys are issued by the ecosystem API under /admin/api-keys. Keys are prefixed with kvn_ and can be revoked at any time.

Webhook endpoints register under /admin/webhooks and deliveries are signed with HMAC-SHA256 in the X-KivuNext-Signature header. Event broadcasting is not yet wired to Hub workflows, so treat registrations as provisional.