Page · Platform

The shared identity protocol underneath every tenant.

Kimezu is a single identity, ownership, access and payment-context layer for multi-application ecosystems. Connected applications receive the same verified actor information regardless of which tenant is in front, so integration code stays consistent.

Standards
OAuth 2.0 · OIDC
Built with
PHP · MySQL · RS256
Region
EU-west · EU-central
The model

Four primitives, shared across every app.

Most authentication systems are designed for single applications. Real systems aren't. Kimezu names the four primitives that actually move between apps and centralises them.

1.1Identity

One person, one identity.

A user authenticates once to Kimezu and is recognised across every connected application, without those apps holding credentials or running their own login.

sub: usr_8f2b3e1c · tenant: rozuro
1.2Access

Permissions decided centrally.

Roles, group memberships, and direct grants are evaluated by Kimezu and applied by your apps. Change a permission once; every app sees it on the next request.

can: publish:article, settle:payment
1.3Ownership

Resources have owners.

Users and groups own things. Ownership rides along with the session so authorization decisions and payment routing land in the right account, every time.

owner: grp_press_eu · role: editor
1.4Payments

Payment profiles, recorded centrally.

Kimezu records where money is supposed to go (Stripe, Mollie, PayPal) and the VAT treatment that applies. Your apps execute the transaction; Kimezu keeps the books consistent.

payment_profile: prf_rozuro_eu

One dashboard, every connected app.

The operator console surfaces every application that talks to Kimezu (login health, agent activity, dormant credentials) in a single view, tenant by tenant.

console.kimezu.com/overview
Kimezu operator dashboard (every connected app on one surface)
Actors

Three actor types share one JWT shape.

Every consuming app receives the same session structure regardless of who's calling. Only actor_type changes, your integration code doesn't have to.

U

User

 authenticated person

A real person signs in to one of your tenants. Same identity recognised across every connected app, no separate accounts.

"actor_type": "user",
"sub": "usr_8f2b...e1",
"tenant": "rozuro",
"groups": ["editors"],
"can": ["publish:article"]
G

Group

 owns resources, receives payment

A workspace, team or org. Owns resources, receives payments, has its own payment profile. Members inherit permissions through membership.

"actor_type": "group",
"sub": "grp_press_eu",
"tenant": "rozuro",
"owners": ["usr_8f2b...e1"],
"payment_profile": "prf_press"
A

Agent

 AI on behalf of an owner

A non-human identity with a revocable API token, scoped to never exceed its owner's permissions. Revoked instantly across every connected app.

"actor_type": "agent",
"actor_id": "agt_indexer_3",
"sub": "usr_8f2b...e1",
"aud": "rozuro.search",
"can": ["read:article"]
!
Principle of least privilege is enforced at grant time. An agent's permissions can never exceed its owner's, Kimezu rejects the grant API call before the token is ever issued. There's no runtime escape hatch.

Apps overview (every registered application, one list).

Each app shows the actor types it accepts, its credential status, and the tenants that have it connected. Rotating a key or revoking an integration is a one-click action.

console.kimezu.com/apps
Kimezu apps overview (every registered application)

App detail (usage, sessions, agents).

Drill into a single application: login volume over time, active sessions, agent tokens issued in its name, and the last permission decisions the protocol made for it.

console.kimezu.com/apps/rozuro
Kimezu app detail (per-application usage, sessions and agent activity)
Sessions & tokens

Verify a session in two lines.

Kimezu issues short-lived JWTs signed with RS256. Your application fetches the public JWKS once per rotation window and verifies tokens locally, no per-request RPC.

Sessions in Kimezu are stateless on the application side. When a user authenticates, Kimezu signs a JWT containing the session shape (identity, tenant, groups, capabilities, payment profile, actor type) and your application validates it offline against a public key from the JWKS endpoint.

Tokens are short (15 minutes) and accompanied by a longer-lived refresh token Kimezu stores. Revocation works two ways: refresh tokens can be invalidated immediately, and the JWKS rotation schedule (24 hours by default) gives you a hard upper bound on token lifetime. Push-revoke via webhook is available on the Operator plan and above.

A consuming app should be able to validate a Kimezu token without touching the internet.

For server-to-server calls (agents, webhooks, signed callbacks) Kimezu uses the same JWT shape with actor_type: "agent". The signature path is identical; only the audience claim differs. One verification function handles every kind of caller your app will ever see.

SESSION   Authorization: Bearer <jwt> 
{
  "actor_type": "user",
  "sub": "usr_8f2b3e1c",
  "tenant": "rozuro",
  "aud": "rozuro.com",
  "iss": "https://id.rozuro.com",
  "iat": 1715760000,
  "exp": 1715760900,
  "groups": ["editors", "press"],
  "can": [
    "publish:article",
    "settle:payment"
  ],
  "payment_profile": "prf_rozuro_eu"
}
// Verify with the public JWKS at
// /.well-known/openid-configuration
Payments

Kimezu records payment context; processors move the money.

Kimezu manages payment profiles (where money should go and how VAT should be treated). Stripe, Mollie and PayPal handle the moving.

a.

Profile = destination + treatment.

A payment profile contains a provider, an account ID, a country, and the lawful basis for any data processed at payment time. Your app reads it; the processor never sees Kimezu.

b.

Provider-aware, country-aware.

Selection follows user preference, app configuration and country default. Stripe for cards, Mollie for iDEAL / SEPA / Bancontact, PayPal where it makes sense.

c.

VAT treatment recorded at payment time.

EU consumer, EU business with valid VAT number (reverse charge), or outside-EU scope. The right rule is applied and stored, so invoices and OSS reporting stay aligned.

d.

Refunds inherit the original treatment.

The same VAT rule that applied to the charge applies to the refund, your books stay clean without manual reconciliation.

Payment routing (the profile that decides where money goes).

Profiles tie a group to a provider, an account ID and a VAT treatment. Every tenant's routing is visible from one surface; changes propagate without a code release.

console.kimezu.com/payments
Kimezu payments (payment-profile routing UI)

Subscription plans.

Recurring billing rides on the same payment profile. Plans live per tenant; price changes apply on the next renewal without re-issuing keys.

console.kimezu.com/payments/plans
Kimezu subscription plans (recurring billing on the same payment profile)

Invoices — the document of record.

Invoices are produced with the VAT treatment recorded at charge time, so the books and the PDF agree. Exportable, queryable, audit-aligned.

console.kimezu.com/payments/invoices
Kimezu invoices (VAT treatment recorded at charge time)
Architecture

The line between protocol and application.

Kimezu is opinionated about where decisions live. The protocol is shared so integration code stays consistent; everything a customer sees is tenant-scoped.

Centralised in the protocol

Same across every tenant.

  • a.Identity store: single source of truth for users, credentials, MFA factors.
  • b.Authorization decisions: permission evaluation runs in Kimezu, enforcement in your app.
  • c.Session shape: actor_type, sub, tenant, groups, can, payment_profile.
  • d.Audit log: HMAC-chained, tamper-evident, queryable.
  • e.Open standards: OAuth 2.0, OIDC discovery, JWKS rotation.
Scoped to each tenant

Different per brand.

  • a.Brand surface: colours, logo, domain, copy, support email.
  • b.Payment profile: Stripe, Mollie, PayPal account routing.
  • c.Groups, roles, permissions: namespaced to that tenant only.
  • d.VAT treatment: billing country, reverse-charge rules, OSS reporting.
  • e.Sign-in surface: magic link, password, MFA (per tenant).

Agents (AI identities with revocable scope).

Every AI agent is a first-class actor with its own token, audit trail and revocation switch. Grants are bounded by the owner's permissions at issue time, not at runtime.

console.kimezu.com/agents
Kimezu agents (AI identities with revocable scope)
Two developers pairing at a laptop in front of a brainstorm board, reading a JWT and writing a guard clause

Two developers pairing at the integration desk

A consuming application validates a Kimezu token in two lines of code. The protocol is what crosses the wire; the keyboard is where someone reads the JWT and writes a guard clause. Most of the work in adopting Kimezu is removing the auth code you were going to write anyway.

Non-goals

The work Kimezu deliberately leaves to other systems.

Honesty about scope is part of the protocol. The list below is contractual, if you need any of these, Kimezu is the wrong tool.

a. No payment processingKimezu records routing and VAT treatment. Stripe, Mollie and PayPal execute. We never hold funds, never settle, never reconcile on your behalf. out of scope
b. No application UISign-in pages and the operator console are ours. Everything else (your app, your dashboard, your customer surface) is yours. out of scope
c. No application dataWe don't store articles, products, transactions or messages. Application data belongs in your application database. out of scope
d. No business logicWorkflows, billing rules, content moderation, none of this runs in Kimezu. We are infrastructure, not framework. out of scope
e. No external SaaS dependenciesKimezu does not depend on third-party identity providers, analytics, or feature flags. Self-hosting works air-gapped. out of scope
f. No proprietary user IDsUUIDs throughout, OIDC-compliant sub claims, documented schema. Migrating away is well-defined and supported. vendor-neutral

Accounts (one person, every tenant they belong to).

An account is a single Kimezu identity visible across every tenant the person has access to. Group memberships, role assignments and active sessions are visible from one record.

console.kimezu.com/accounts
Kimezu accounts (users, tenants, sessions on one record)
Read next

See how operators actually use it.

The operator console is the surface a platform team lives in. One console, every tenant, every audit trail in one place.

Operator experience → Read the documentation
Quickstart
A single sandbox tenant

Live OIDC discovery, real JWKS rotation, one tenant. Get started →

API reference
Every endpoint, every claim

Full OpenAPI 3 spec with copy-pasteable examples. Open reference →