TIKTI | Auth & Authz Provider

How It Works

CORE FEATURES

Strict Isolation

Context-aware tokens. No access token is issued without a valid tid (Tenant ID) and verified membership. Prevents horizontal privilege escalation by design.

Identity Swapping

Exchange high-friction Identity Tokens (HS256) for service-scoped Access Tokens (RS256). Ideal for autonomous agents requiring specific scopes.

Cryptographic Audit

Public JWKS endpoints allow offline validation by any resource server. Zero shared secrets between microservices.

CLI First

Full control over tenant lifecycle from your terminal. Manage tenants, rotate keys, and provision workers entirely via CLI.

NVMe Persistence

KVRocks backend stores millions of user sessions with a minimal RAM footprint while maintaining sub-millisecond access times and full durability.

Cloud Native

Stateless application tier scales horizontally via Kubernetes HPA. Standard Helm charts provided for high-availability deployment.

Get Started

# 1. Initialize session
$ tikti init --host https://api.tikti.io
$ tikti auth login --user root@corp.sys

✔ Session active.

# 2. Provision Tenant
$ tikti tenant create --slug codecompany

# 3. Exchange Token (Worker Flow)
$ tikti token exchange \
    --aud backend-worker \
    --scope "jobs:read jobs:write" \
    --tenant codecompany \
    --sub worker-01

✔ Access Token (RS256) minted.
eyJhbGciOiJSUzI1NiIsImtpZCI6InRpa3RpLTIwMjY..._

// POST /v1/accounts/token/exchange
{
  "idToken": "eyJ... (HS256)",
  "audience": "backend-worker",
  "tenantId": "tenant-1",
  "subject": "worker-1",
  
  // Scopes
  "scopes": [
    "jobs:read",
    "jobs:write"
  ],
  
  // Custom Claims
  "eventTypes": [
    "video_processing"
  ],
  "ttlSeconds": 3600
}

// GET /.well-known/jwks.json
{
  "keys": [
    {
      "kty": "RSA",
      "kid": "tikti-2026-01",
      "use": "sig",
      "alg": "RS256",
      "n": "rvt82...",
      "e": "AQAB"
    }
  ]
}

# Cache-Control: public, max-age=300
# Verifiable by any standard JWT library.

Benchmark & Latency

TIKTI optimizes for sub-millisecond session lookups and high-density token issuance using KVRocks SSD persistence.

Token Issuance Latency

LATENCY

< 1ms

Session Lookup (99th)

10M+

Sessions per Instance

TIKTI maintains predictable latency even under high load by utilizing RocksDB-backed session storage.

System Specifications & FAQ

Why separate Identity Tokens from Access Tokens?

The TIKTI Approach: We use HS256 for the initial Identity Token (internal session) to maintain millisecond latency during login. We then exchange this for a scoped Access Token (RS256) for downstream services. This allows Resource Servers to validate tokens offline using cached JWKS without ever possessing a secret key.

How does TIKTI handle high-throughput persistence?

We use KVRocks. It implements the Redis protocol but stores data on NVMe SSDs via RocksDB. This allows TIKTI to store millions of user sessions with a minimal RAM footprint while maintaining sub-millisecond access times and full durability.

How do I deploy this to production?

TIKTI is Cloud Native. The application tier is stateless and scales horizontally via standard Kubernetes HPA. We provide a Helm chart that provisions the TIKTI deployment and the KVRocks StatefulSet.

Does TIKTI lock me into a proprietary SDK?

No. TIKTI implements standard JWTs with compliant claims. Any library compatible with RS256 signing and JWKS discovery works out of the box.