Core Concepts & Features

This page explains the foundational ideas behind TideCloak: what problem it solves, how the pieces fit together, and why the architecture is structured the way it is. If you just want to get something running, start with the Quickstart and come back here when you want to understand what's happening under the hood.

---

The Stack at a Glance

───────────────────────────────────────────────────────────────────────
│                           Your Application                          │
│                    (consumes JWTs, calls APIs)                      │
──────────────────────────────────┬────────────────────────────────────
                                  │
                                  ▼
───────────────────────────────────────────────────────────────────────
│                            TideCloak                                │
│         Keycloak-based IAM with authority removed from the box      │
│                                                                     │
│   • OIDC/OAuth endpoints      • Admin console                       │
│   • User federation           • Realm & client management           │
│   • Token issuance            • Policy enforcement                  │
│                                                                     │
│   ⚠️  Cannot sign tokens or authenticate users on its own           │
│      must coordinate with the Fabric for any cryptographic op       │
──────────────────────────────────┬────────────────────────────────────
                                  │
             ─────────────────────┴──────────────────────
            │                                           │
            ▼                                           ▼
─────────────────────────               ───────────────────────────────
│  Secure Web Enclave   │               │    Cybersecurity Fabric     │
│        (SWE)          │──────────────►│                             │
│                       │   threshold   │  Decentralized network of   │
│  Browser-side dealer  │   operations  │  independent nodes holding  │
│  for user flows       │               │  key fragments              │
│                       │               │                             │
│  • Initiates auth     │               │  • Threshold cryptography   │
│  • Blinds credentials │               │  • Multi-party computation  │
│  • Verifies proofs    │               │  • Zero-knowledge proofs    │
─────────────────────────               ───────────────────────────────
                                                      │
                                                      ▼
                                        ───────────────────────────────
                                        │    No single node holds     │
                                        │    a complete key. Ever.    │
                                        ───────────────────────────────

The key insight: TideCloak has no signing keys. The authority that would normally live inside an IAM (the keys that sign tokens, the hashes that verify passwords, the admin overrides that can bypass rules) has been moved out of the box entirely and into the Fabric, where it's distributed across independent parties.

---

Core Concepts

Tide — Security architecture where secrets never exist in one place

Tide is an approach to security architecture based on a simple premise: if a secret exists in one place, it can be stolen from that place.

Traditional security focuses on making that place harder to reach: firewalls, encryption at rest, access controls, monitoring. But once an attacker (or a rogue insider, or a compromised vendor) reaches the place where secrets live, the game is over. The attacker wins.

Tide eliminates the place.

Instead of storing a key and protecting it, Tide systems generate keys that are never assembled. The key exists only as fragments distributed across independent nodes operated by different parties. To use the key (to sign, decrypt, or authenticate), those nodes must cooperate, but they do so without ever combining their fragments. The key is used, but never materialized.

This isn't just defense-in-depth. It's a different threat model:

• There's no vault to breach
• There's no admin with root access
• There's no vendor who can be compelled to hand over keys
• There's no single point that, if compromised, unlocks everything

Tide calls this Ineffable Cryptography: cryptographic operations on keys that can never be expressed in whole.

Cybersecurity Fabric — Decentralized network performing threshold cryptography

The Cybersecurity Fabric is the decentralized network that makes Tide's approach practical.

What it is: A globally distributed set of independent nodes (called ORKs, or Orchestrated Recluders of Keys) that collectively store key fragments and perform cryptographic operations without any single node seeing a complete key.

How it works:

1. Key generation: When a key is created, it's generated in a distributed ceremony. Each node creates a fragment. No node ever sees the whole key: not during generation, not during use, not ever.
2. Threshold operations: To sign a token or decrypt data, a minimum number of nodes (the threshold) must participate. Each node performs a partial computation on its fragment. The partial results are combined to produce a valid signature or decryption, but the key itself is never reconstructed.
3. Parallel performance: Nodes performing a cryptographic operation do so in parallel, to ensure enterprise grade performance.
4. Honest-minority resilience: The protocol is designed so that even if some nodes are compromised or malicious, they cannot extract the key or corrupt the operation. As long as enough honest nodes participate, the system works correctly and securely.
5. Zero-knowledge proofs: Every operation produces cryptographic proofs that can be independently verified. You don't have to trust that the Fabric did the right thing, you can check.

What this means for you:

• No key material to secure, rotate, or worry about leaking
• No vendor (including Tide) that holds keys to your data
• Policy enforcement is verifiable cryptographically

The Fabric currently runs on a testnet operated by Tide and partners. The path to a fully decentralized mainnet with independent operators is underway.

Secure Web Enclave (SWE) — Browser-side coordinator for cryptographic operations

The Secure Web Enclave is the browser-side component that coordinates cryptographic operations between the user and the Fabric.

Why it exists: The Fabric can perform operations on key fragments, but someone needs to initiate those operations, collect the partial results, and assemble the final output. For user-facing flows (login, consent, credential entry), that coordinator runs in the user's browser.

What it does:

• Initiates authentication: When a user enters credentials, the SWE blinds them (transforms them so the Fabric nodes can process them without seeing the actual values) and coordinates the distributed PRISM protocol.
• Assembles proofs: The SWE collects partial responses from Fabric nodes, verifies they're well-formed, and combines them into the final authentication token or signature.
• Maintains session keys: After authentication, the SWE holds an ephemeral session key that's bound to the specific browser session. This key is used to decrypt data that's been sealed specifically to this session, data that no one else (not even the Fabric nodes) can access.
• Verifies integrity: The SWE is delivered with Subresource Integrity (SRI) hashes. If the code has been tampered with, the browser won't execute it. And because the Fabric's responses include zero-knowledge proofs, the SWE can verify that the Fabric behaved correctly.

Trust model: You don't have to trust the SWE to keep secrets because it never sees complete keys. You don't have to trust that it's running the right code because SRI and the proofs let you verify. The SWE is an "untrusted dealer": it coordinates, but it can't cheat.

For a detailed technical breakdown, see Secure Web Enclave.

TideCloak — Keycloak-based IAM with authority delegated to the Fabric

TideCloak is an Identity and Access Management server based on Keycloak, RedHat's open-source IAM platform. It provides the same OIDC/OAuth 2.0 capabilities, admin console, user federation, and client management that Keycloak users expect.

What's different: The cryptographic authority that normally lives inside a Keycloak instance (the signing keys, the password verification, the token minting) has been replaced with calls to the Cybersecurity Fabric.

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

What this means for you:

• Standard integration: TideCloak exposes standard OIDC/OAuth endpoints. Your app integrates the same way it would with any IAM.
• No key management burden: You don't store, rotate, or protect signing keys. The Fabric handles it.
• Breach containment: If your TideCloak instance is compromised, the attacker gets... nothing useful. They can't forge tokens, dump password hashes, or escalate privileges.
• Quorum-enforced administration: Critical changes (adding admins, modifying policies) require multi-party approval through the Fabric. No single rogue admin can subvert the system.

TideCloak is the practical entry point for most developers. You run it (locally in dev mode, or deployed in production), point your app at it, and get IAM with the authority layer removed.

For a look under the hood, see Architecture.

---

Features

BYOiD (Bring Your Own Identity) — Zero-knowledge, decentralized authentication

BYOiD is TideCloak's decentralized authentication protocol that proves a user's identity without revealing credentials to any single node or system.

The problem: In traditional IAM, when you authenticate, the server verifies your password by comparing it to a stored hash. If that server (or its database, or its admin) is compromised, your credentials are at risk. Even secure hashing doesn't help if an attacker can modify the authentication logic or inject malicious code.

The solution: BYOiD uses a zero-knowledge authentication protocol where:

• Your credentials never leave your device in plaintext
• The Fabric verifies your identity through threshold cryptography without any single node seeing your password
• No password hashes are stored anywhere
• Even TideCloak administrators cannot impersonate users or access credentials

How it works:

1. Credential blinding: When you enter your password, the Secure Web Enclave blinds it (transforms it cryptographically) before sending it to the Fabric
2. Threshold verification: Multiple Fabric nodes each perform a partial verification operation. No single node can verify the password alone
3. Zero-knowledge proof: The nodes provide cryptographic proof that verification succeeded without revealing any information about the password itself
4. Session key generation: Upon successful authentication, an ephemeral session key is generated in your browser that's unique to this session and never leaves your device

What this means:

• True self-sovereign identity: users control their authentication, not the IAM provider
• No offline attacks: there are no password hashes to crack
• No admin impersonation: even privileged administrators cannot bypass authentication or reset passwords without user participation
• Continuous verification: every authentication can be independently verified to ensure the system operated correctly

For technical details, see BYOiD Authentication.

Hermetic End-to-End Encryption (E2EE) — Data sealed to user sessions with ephemeral keys

Hermetic E2EE ensures that sensitive data can only be decrypted by the authorized user session, and remains permanently inaccessible to everyone else, including system administrators, cloud providers, and even Tide.

The problem: Traditional "encrypted at rest" and "encrypted in transit" still leave a gap: when data is decrypted for processing, it's vulnerable. Someone with system access (an admin, a compromised server, a malicious cloud provider) can intercept it at that moment.

The solution: Hermetic E2EE seals data so it can only be unlocked by a specific user session's ephemeral key, which exists only in the user's browser or application, never on any server.

How it works (the complete flow):

1. Provable authentication: BYOiD proves user identity via zero-knowledge ensuring the right user is requesting a decryption
2. Ephemeral session key: After a successful BYOiD authentication, a unique session key is generated on the users's device (in the TPM)
3. Sealed authorization token: The authorization proof is encrypted specifically to the user's session key, so only their session can decrypt it
4. Data decryption at the edge: When the user requests data, it's decrypted by the Fabric and re-encrypted to their session key before transmission. Only their device can decrypt the final result
5. Hermetic seal: Even if someone intercepts the encrypted data or compromises a server, they cannot decrypt it because the session key never existed anywhere except the user's device

What this means:

• Data is never exposed in plaintext on any server
• Administrators cannot access user data, even with root privileges
• Breaches yield only encrypted data with no feasible key to unlock it
• The entire chain, from authentication to authorization to data access, is cryptographically sealed to the legitimate user session

For technical details, see Hermetic E2EE.

Quorum Enforced Governance — Multi-admin approval and threshold signatures

Quorum Enforced Governance ensures that critical administrative actions, such as modifying roles, permissions, or token policies, require multi-party approval before taking effect.

The problem: In traditional IAM systems, a single administrator with sufficient privileges can unilaterally make changes that affect the entire system. A compromised admin account, a rogue insider, or a simple misconfiguration can lead to unauthorized access, privilege escalation, or security breaches.

The solution: TideCloak enforces a quorum-based approval process for sensitive operations:

• No single administrator can modify identity policies, rotate signing keys, or alter access controls alone
• Changes must be proposed, reviewed, and approved by multiple administrators
• Approvals are cryptographically signed using Threshold Signature Schemes (TSS), so the signing key itself is never held by any individual

How it works:

1. Change request: An administrator proposes a change (e.g., adding a new admin role, modifying JWT claims, rotating a signing key)
2. Quorum distribution: The proposal is distributed to the administrator quorum for review
3. Authenticated voting: Each admin authenticates and casts an approve or deny vote
4. Threshold signing: If a majority approves, the Fabric cryptographically signs the change using TSS; no single node or admin holds the complete signing key
5. Audit logging: Every proposal, vote, and outcome is logged with timestamps and cryptographic proofs

What this means:

• Insider threats are mitigated: no single person can subvert the system
• The JWT signing key and issuance process are protected by distributed authority
• All administrative actions are auditable and tamper-evident
• Regulatory compliance requirements for separation of duties are met by design

For technical details, see Quorum Enforced Governance.

Tamper-proof Authorization — OAuth 2.0 extended with decentralized infrastructure

Tamper-proof Authorization extends the standard OAuth 2.0 Authorization Code Flow with decentralized infrastructure, ensuring that every step of the authorization process is cryptographically verified and resistant to tampering.

The problem: In conventional authorization flows, the authorization server holds all the keys. If that server is compromised, an attacker can forge tokens, escalate privileges, or impersonate any user. The entire security model depends on protecting a single point of failure.

The solution: TideCloak distributes authority across the Cybersecurity Fabric:

• Authorization codes and tokens are validated through distributed consensus, not a single server
• Token signing uses Secure Multiparty Computation (SMPC), so the signing key is never reconstructed
• Session keys are cryptographically bound to the authenticated user and verified across multiple nodes

How it works:

1. Decentralized authentication: Users authenticate using BYOiD's zero-knowledge protocol; credentials are verified across the Fabric without any single node seeing the password
2. Distributed token issuance: When tokens are issued, each Fabric node performs a partial signing operation on its key fragment; the results combine into a valid signature without the key ever existing in one place
3. Session key binding: The user receives a session key that is cryptographically bound to their identity and scoped to specific permissions
4. Consensus-based validation: Any verification of tokens or session keys is performed through distributed consensus across Tide nodes

What this means:

• No single point of failure: compromising one node or even TideCloak itself doesn't allow token forgery
• Cryptographic proof of authorization: every token can be independently verified
• User ownership: the Consumer Master Key (CMK) remains under user control and is never exposed or reconstructed
• Zero-trust by design: authority is validated cryptographically, not assumed based on network position

For technical details, see Tamper-proof Authorization.

Programmable Policy (Forseti) — Custom authorization logic enforced by the Fabric

Programmable Policy, powered by the Forseti engine, enables developers to write custom authorization rules that are enforced directly by the Cybersecurity Fabric, not by application code that could be bypassed.

The problem: Traditional authorization lives in application code. A compromised server, a rogue admin, or a simple bug can bypass access controls entirely. Even if you write perfect code, someone with sufficient access can "patch it out."

The solution: Forseti moves authorization logic into the Fabric itself:

• Authorization rules are written as C# contracts that run in sandboxed environments on ORK nodes
• Contracts are identified by the SHA512 hash of their source code, so any tampering changes the identity
• The Fabric mathematically cannot produce signatures or decrypt data unless the contract logic passes independently by the threshold of Fabric nodes
• Execution is gas-metered to prevent resource exhaustion and infinite loops

How it works:

1. Contract definition: Developers write C# contracts implementing the IAccessPolicy interface with three validation stages: ValidateData (request parameters), ValidateApprovers (quorum signatures), and ValidateExecutor (requester roles)
2. Commitment: Contracts are attested and committed to the Fabric; the Contract ID is derived from the SHA512 hash of the source code
3. Request processing: When a user requests a cryptographic operation, each ORK node independently executes the contract in an isolated sandbox
4. Threshold consensus: Only if enough nodes (typically 14 of 20) independently validate the request does the operation succeed

What this means:

• Authorization logic cannot be bypassed by compromising the application server
• Custom business rules (geo-fencing, time windows, M-of-N approvals) are cryptographically enforced
• Even a full RCE on your backend yields nothing: the server is a "dumb terminal" with no inherent authority
• All authorization decisions are auditable and tamper-evident

For technical details, see Programmable Policy (Forseti).

---

Summary

Concept	What it is	Role in the stack
Tide	Security philosophy based on keys that never exist in one place	The "why"
Cybersecurity Fabric	Decentralized network of nodes performing threshold cryptography	The authority layer
Secure Web Enclave (SWE)	Browser-side coordinator for user cryptographic operations	The user's entry point
TideCloak	Keycloak-based IAM with authority delegated to the Fabric	The product you integrate
BYOiD Authentication	Zero-knowledge, decentralized authentication protocol	User identity verification
Hermetic E2EE	Data sealed to user sessions with ephemeral keys	End-to-end data protection
Quorum Enforced Governance	Multi-admin approval and threshold signatures for JWT issuance	Administrative controls
Tamper-proof Authorization	OAuth 2.0 flow extended with decentralized infrastructure	Access control
Programmable Policy (Forseti)	Custom C# authorization logic enforced by the Fabric	Policy enforcement

The bottom line: TideCloak gives you a standards-compliant IAM where the usual catastrophic failure modes (key theft, admin compromise, vendor breach) don't apply because the keys those attacks would target don't exist in any single place to steal.