Identity Enforcement Gateway

Every request passes through a central identity and policy engine before reaching any backend.

One system replaces your access stack.

How it works

User access
Users / Consumers Browser, CLI, API
Hexon Cluster Authenticate · Check policy · Forward or deny
Backends Signed headers and injected JWT
Authentication is enforced at the gateway — not in your applications. Backends receive verified identity via signed headers and standard tokens, with no code changes required. The identity provider and access layer are built into the same system.
Authentication
Internal methods WebAuthn · TOTP · X.509
Kerberos · Magic link
Email OTP · JIT 2FA
External federation LDAP · AD · Okta · Entra · Google
OIDC RP
API
Hexon Cluster Session · MFA step-up · Audience per application
Signed Ed25519 headers User · Email · Groups
Per-request verification
JWT Bearer token OAuth 2.0 SSO
Per-route injection
Multiple built-in methods like passkeys that work with your current Identity Provider. Access is scoped per application, with optional MFA. Your services receive verified identity — no code changes required.
Identity & policy
Directory sources LDAP · AD · SCIM
Multi-provider merge
Priority resolution
Hexon Cluster Groups · Nested DAG traversal
Fresh per request
Per-protocol enforcement Proxy: per-route groups
SSH/SQL: group-based ACL
Network: per-peer firewall
Identity syncs from your existing directory (LDAP, Active Directory, or SCIM). The same groups control access across all systems. Disable a user once — access is revoked everywhere.
Service to service
Service A X.509-SVID from ACME CA
mTLS SPIFFE trust domain
Service B X.509-SVID from ACME CA
Services authenticate directly to each other using mutual TLS. Traffic flows without going through the gateway. The gateway issues identity — it doesn't need to sit in the path.
Control plane
Node A Leader
Cluster RPC NATS/JetStream · mTLS · X3DH · AES-256-GCM
Node B Replica
All nodes coordinate securely and stay in sync. Changes — like disabling a user or updating access — apply everywhere. Built on a distributed, fault-tolerant architecture.
Threshold signing
Node A Encrypted shard
Node B Encrypted shard
Node C Encrypted shard
Signed output TLS certificates · OIDC tokens · PATs · SSH CA
The signing key never exists on a single node. Keys are split and used collaboratively via threshold cryptography. No single system can access them — no external HSM required.
End-to-Origin Encryption
Browser ECDH P-256 + AES-256-GCM
WebCrypto API
E2OE channel (encrypted)
CDN sees ciphertext
WAF sees ciphertext
Hexon Decrypts · Authenticates
Forwards to backend
Baseline ECDH + AES-GCM — encrypted channel
Tier 1 + WebAuthn channel binding — hardware-attested
Sensitive data is encrypted end-to-end — beyond TLS. Intermediaries like CDNs or proxies only see ciphertext. Encryption is bound to user identity, preventing interception or relay attacks.

Every capability. One deployment. Zero sprawl.