From Theory to Integration: TideCloak | Cyber Immunity Whitepaper

Introduction: The Inversion of Complexity

Despite the deep cryptographic complexity required to decentralize trust, enterprise adoption depends entirely on providing a seamless, standard integration path for developers. For a developer evaluating this architecture, one question matters:

How hard is it to actually use?

The answer is an architectural inversion: the more sophisticated the underlying cryptography, the simpler the developer experience can be. The security guarantees are built into the protocol, not into the developer's implementation. A developer using TideCloak writes standard OIDC integration code. The architecture ensures security by construction.

TideCloak: Keycloak With the Authority Removed

TideCloak is an Identity, Immunity & Access Management (IIAM) server built on Red Hat's widely used open-source Keycloak platform. It provides the same OIDC/OAuth 2.0 endpoints, admin console, user federation, JWKS, and role-based access controls.

What distinguishes TideCloak is what has been removed from the backend. The cryptographic authority normally inside a Keycloak instance - signing keys, password hashes, administrative overrides - has been replaced with calls to the decentralized Tide Cybersecurity Fabric. From the outside, TideCloak integrates identically to a standard identity provider. From the inside, it holds no actionable key material.

In Standard Keycloak	In TideCloak
JWT signing key stored on the server.	Signing key exists only as fragments in the Fabric; TideCloak requests threshold signatures.
Password hashes stored in the database.	Passwords verified via zero-knowledge protocol; no hashes stored.
Admin can unilaterally reset any user's password.	Password reset requires user participation; admin cannot impersonate.
Root access to server = root access to IAM.	Root access reveals no key material.
Compromised IAM = forged tokens.	Compromised TideCloak cannot forge tokens without subverting 14 independent Fabric nodes.

The developer implication: If your application integrates with Keycloak, switching to TideCloak requires changing the IAM server URL. The integration code, APIs, and JWT format remain the same. For applications using other OIDC providers, migration requires standard OIDC client reconfiguration (discovery endpoint, issuer URL, client credentials) - the protocol is the same.

The SDK: From `npm init` to Production

TideCloak operates as a standard OIDC provider, but Tide provides SDKs that integrate the Secure Web Enclave (SWE) and Hermetic E2EE into the developer workflow. The TideCloak Next.js SDK is the reference implementation.

bash

npm init @tidecloak/nextjs@latest my-app
cd my-app && npm run dev

This scaffolds a complete application with authentication (login/logout, silent SSO), Edge middleware (route protection with role checks), API verification (server-side JWT validation), E2EE (tag-based encryption/decryption), and redirect handling.

text

my-app/
├── app/
│   ├── api/protected/route.js    # Protected API route
│   ├── auth/redirect/page.jsx    # OIDC redirect target
│   ├── home/page.jsx             # Post-login landing
│   ├── public/silent-check-sso.html
│   ├── layout.jsx                # App entry (Provider wraps here)
│   └── page.jsx                  # Login / entry page
├── tidecloak.json                # TideCloak adapter config
├── middleware.js                 # Edge middleware
└── package.json

FIGURE 21: TideCloak Next.JS Project Scaffold

Without writing cryptographic code, the developer has deployed zero-knowledge authentication, role-based access control, edge protection, and E2EE readiness.

The Developer API Surface

The complete SDK API consists of standard React components, hooks, and asynchronous functions.

Session and Authentication:

<TideCloakProvider config={...}> - Wraps the app. Initializes the SWE, manages sessions and silent SSO.
useTideCloak() - Hook exposing: authenticated, login(), logout(), token, tokenExp, refreshToken().
<Authenticated> / <Unauthenticated> - Guard components for conditional rendering.

Token Access and Claims:

getValueFromToken(key) / getValueFromIdToken(key) - Read claims from access or ID tokens.
hasRealmRole(role) / hasClientRole(role, client?) - Check realm or client-level roles.

Route Protection:

createTideCloakMiddleware({ config, protectedRoutes, onFailure, onError }) - Returns Edge middleware that verifies tokens and checks roles before the request reaches the page or API.
verifyTideCloakToken(config, token, allowedRoles?) - Server-side JWT verification. This is the Asgard component (Article 7) - the backend Dealer Library for Node.js. Available within the SDK (@tidecloak/nextjs/server) or as a standalone package (@tidecloak/verify) for non-Next.js backends.

End-to-End Encryption:

doEncrypt([{ data, tags }]) - Encrypt data with tag-based permissions.
doDecrypt([{ encrypted, tags }]) - Decrypt data via threshold re-encryption; cleartext resolves in the browser only.
Access gated by roles: _tide_<tag>.selfencrypt / _tide_<tag>.selfdecrypt.

What is absent from this API: No key management functions. No HSM configuration. No password hashing parameters. No encryption key rotation. No certificate management. These concepts do not exist in the developer's world because the architecture eliminates them.

For deployments requiring credential-free authentication, the Authenticator App (Article 7) provides an independent out-of-band path - the user's password never enters the browser, and the App cross-verifies the session via the Browser Key (BRK).

The Invisible Mapping: Theory to API

Loading diagram...

FIGURE 22: Developer Integration Surfaces

Each developer action maps to invisible protocol machinery:

Developer Action	What They Write	What Actually Happens (Invisible)	Article
User clicks "Login"	`login()`	SWE opens → PRISM protocol → credentials blinded → CMK ORKs verify in ZK → blind signature → session key	4, 7
SDK checks auth	`authenticated`	VVK ORKs threshold-sign JWT → Doken issued → session validated	5
Middleware checks roles	`protectedRoutes: {'/admin': ['admin']}`	JWT verified against VVK-signed JWKS → Fabric-sealed roles extracted	5, 6
API verifies token	`verifyTideCloakToken(config, token)`	Asgard verifies signature against distributed VVK public key	5, 7
Encrypt data	`doEncrypt([{data, tags}])`	Doken authorizes → Forseti checks tag roles → ORKs compute partial ElGamal → SWE interpolates ciphertext	6
Decrypt data	`doDecrypt([{encrypted, tags}])`	Doken authorizes → Forseti checks → ORKs compute partial proxy re-encryption → SWE subtracts session mask → cleartext in browser only	6
Token refresh	Built-in (no code)	Silent SSO → SWE re-authenticates → fresh JWT + session key	4, 5, 7
Every ORK operation	(Invisible)	Anonymous voucher allocated → Payer validates → credit checked → ORK executes	8
Key generation at signup	(Invisible)	Nested Shamir DKG → 20 shards → TWELVE-MAP registration → ZK proofs	3
Admin modifies policy	Admin console	Change requires quorum co-signatures → VVK ORKs verify threshold before sealing	5

The developer writes standard React hooks, OIDC patterns, and two encryption functions. Behind each call, the system executes threshold cryptography across 20 independent nodes, validates vouchers, enforces policies, and produces tamper-proof tokens - in real-time, with sub-second latency, invisible to the application.

What Disappears From the Developer's Responsibility

Gone - no longer the developer's concern:

Traditional IAM Responsibility	Why It Disappears in TideCloak
Securing JWT signing keys	No signing key exists on the server. VVK is distributed across the Fabric.
Password hash breach liability	No password hashes exist. PRISM verifies credentials in zero-knowledge.
Key rotation procedures	Keys are born distributed; healed and rotated without assembly (Article 3).
HSM procurement and management	Commodity hardware only. Threshold math replaces TEEs and HSMs.
"Break glass" admin procedures	No break-glass backdoor. Recovery is quorum-governed.
Encryption key management	E2EE keys distributed across Fabric. Decryption requires live session key.
Database encryption for sensitive fields	Per-field tag-based E2EE. Database holds only ciphertext.
Admin privilege escalation prevention	Quorum governance. No single admin can escalate (Article 5).
Password breach notification	No password material to breach.
Certificate pinning for JWT verification	Standard JWKS endpoints return Fabric-signed keys.

Remains - still the developer's concern:

Responsibility	Why It Remains
Application logic correctness	Tide secures identity and encryption, not business logic.
Role assignment design	Which roles exist and who receives them is a business decision.
Input validation and sanitization	Standard web security (XSS, injection) still applies.
Transport layer security (HTTPS)	Standard web requirement.
Redirect URI configuration	Standard OIDC requirement.
Tag-based E2EE role assignment	Deciding which tags protect which fields is a design decision.

Integration Patterns and Flows

Normal Authenticated Access

User visits the app and clicks Login.
App redirects to TideCloak → TideCloak redirects to the Secure Web Enclave.
User authenticates via PRISM zero-knowledge in the SWE (or via Authenticator App for credential-free flow).
Fabric issues proofs. SWE returns tokens (VVK-signed JWT, session-bound Doken).
Edge middleware verifies JWT signature and role claims.
Protected page renders.

Hermetic E2EE Decryption

Protected page requests encrypted field from the API.
Backend verifies _tide_<tag>.selfdecrypt role, returns ciphertext. No server-side decryption.
Frontend passes ciphertext to doDecrypt().
SWE presents Doken to ORK swarm. Each ORK evaluates Forseti policy, computes partial proxy re-encryption.
SWE interpolates, subtracts session mask → cleartext in the authorized browser only.

In both flows, the developer writes standard API calls and React state management. The Fabric, vouchers, and threshold operations are invisible.

The Adoption Path

Greenfield:

bash

npm init @tidecloak/nextjs@latest my-app

The scaffold includes authentication, middleware, API verification, and E2EE.

Existing Keycloak:

Deploy TideCloak (Docker available).
Download adapter config from TideCloak admin console.
Replace the Keycloak adapter config in your app.
(Optional) Add E2EE with doEncrypt() / doDecrypt().

Existing OIDC (non-Keycloak):

Deploy TideCloak.
Update OIDC client configuration (discovery endpoint, issuer URL).
Standard OIDC - no SDK required (SDK adds E2EE).

What does NOT change: OIDC/OAuth flows, JWT format, JWKS verification, role claim structure, redirect URI patterns.

What changes (invisible to the developer): JWTs signed by distributed key. Authentication is zero-knowledge. Admin operations require quorum. E2EE is a first-class operation. Every operation is economically gated and auditable.

Closing: The Full Circle

Article 1 identified the structural reason breaches persist. The existence of singular, complete authority artifacts. A signing key, an admin credential, a password database. Each is a single point whose compromise yields everything.

The answer was not better perimeter defense. It was removing the authority artifact. Article 2 defined Ineffable Cryptography, the suite of cryptographic primitives and protocols that allow keys to be generated, operated, and governed in distributed pieces without ever materializing, and the Cybersecurity Fabric that implements it across a decentralized network of independently operated nodes. Articles 3 through 9 built each layer: distributed key generation, zero-knowledge authentication, quorum governance, threshold operations, verifiable client SWE, and anonymous settlement.

Article 10 demonstrates the payoff. A developer uses all of it by writing standard OIDC integration code and two encryption functions. The architecture is sophisticated because the threat landscape demands it. The developer experience is simple because the architecture allows it. Security is not a developer burden. It is a structural property of the system.

This is Cyber Immunity. Systems rearchitected so that authority is never within direct reach of any system, operator, or attacker, and inevitable breaches cannot escalate into catastrophic damage. Decentralizing authority for digital resilience.