SecureCom — Token-Based Secure Communication Boilerplate

What it does

Every request is split, authenticated, validated in two stages, merged, executed, and re-split — with no single component able to forge a message on its own.

                    ┌─────────────────────────────────────────────┐
                    │              SecureComClient               │
                    │  (split request → 3 pieces, merge response)│
                    └──────┬──────────────┬──────────────┬───────┘
                           │              │              │
              Token A      │   Token B    │   Token C    │
              Profile 2    │   Profile 12 │   Profile 18 │
                           ▼              ▼              ▼
                    ┌────────────┐┌────────────┐┌────────────┐
                    │  Public    ││  Public    ││  Public    │
                    │ Backend α  ││ Backend β  ││ Backend γ  │
                    │ (2-stage   ││ (2-stage   ││ (2-stage   │
                    │  validate) ││  validate) ││  validate) │
                    └─────┬──────┘└─────┬──────┘└──────┬─────┘
                          └──────┬──────┘──────────────┘
                                 ▼
                    ┌────────────────────────┐
                    │   Private Merge        │
                    │   Backend (internal)   │
                    │  merge → execute →     │
                    │  sign + split response │
                    └────────────────────────┘

The round-trip

Six stages, from first connection to the verified merged result.

STEP 1

Authenticate

Client solves a one-time challenge and signs it with a registered Ed25519 key (proof-of-possession). The auth backend returns a signed JWT, a rotated refresh token, and a per-token HMAC secret.

STEP 2

Split

The payload is split into N pieces — one per configured channel. The piece count is server-authoritative, never client-controlled.

STEP 3

Prove + send

Each piece carries a per-request proof (HMAC for Standard, Ed25519 for Elevated/High) plus an Ed25519 piece signature, sent in parallel.

STEP 4

Validate ×2

Each public backend does a local JWT/JWKS/revocation pre-check, then an authoritative round-trip to the auth backend that consumes the one-time challenge (no replay).

STEP 5

Merge + sign

The merge backend verifies every piece signature, waits for all N pieces, executes once, then signs each response piece with its own key.

STEP 6

Verify + merge

The client verifies each response signature against the provisioned merge public key, then merges the pieces into the final result.

Risk-adaptive security levels

The auth backend can elevate a requested profile based on policy and observed behaviour.

Profile	Value	Proof required
`Standard`	2	HMAC-SHA256 with the per-token secret
`Elevated`	12	Ed25519 signature (registered key)
`High`	18	Ed25519 + multi-factor / hardware-style proof

Two trust domains, four databases

The .NET Aspire host wires two independent auth backends, each owning its own pair of MongoDB databases. ChannelAuth = ["Auth1","Auth1","Auth2"].

 Auth1 (SecureComAuth1)  ──owns──>  mongo-1 → securecom-1  ┐ HMAC piece 0 + client-key piece 0
                                     mongo-2 → securecom-2  ┘ HMAC piece 1 + client-key piece 1

 Auth2 (SecureComAuth2)  ──owns──>  mongo-3 → securecom-3  ┐ HMAC piece 0 + client-key piece 0
                                     mongo-4 → securecom-4  ┘ HMAC piece 1 + client-key piece 1

Every per-token HMAC secret and every client public key is XOR-split across an auth backend's two databases — reassembly requires all pieces, so no single database ever holds a whole secret or key. The two auth domains share no databases.

Key features

A security-first design, enforced end-to-end.

Proof-of-possession

Clients sign a challenge nonce with a registered Ed25519 key — a subject name alone is never enough.

Two-stage validation

Fast local JWKS/revocation check, then an authoritative nonce check the auth backend alone can perform.

Client-signed pieces

Every request piece is signed and verified at the merge backend before execution.

Signed responses NEW

The merge backend signs every response piece so clients can verify the merged result end-to-end.

Split secrets

HMAC secrets and client keys are XOR-split across isolated databases — fail closed if any piece is missing.

Anti-replay

One-time challenges are consumed on validate; monotonic sequence numbers and timestamps prevent replay.

Refresh rotation

Refresh tokens rotate on every use; reuse revokes the whole subject (theft detection).

Key rotation

RSA signing keys rotate on schedule with a JWKS overlap window.

mTLS (opt-in)

Mutual TLS for service-to-service and client calls, chained to a private CA.

Observability

OpenTelemetry traces/metrics/logs with the Aspire dashboard and Seq.

How it compares (1–10)

Scored against real-world systems.

Dimension	Score
Authentication & token handling	8
Anti-replay & freshness	9
Data-at-rest secret protection	8
Integrity / anti-tamper	9
Transport security (mTLS opt-in)	7
Operational / production hardening	6

Overall: 8.5 / 10 on security design. A typical JWT + HTTPS API sits around 4–5; a solid OAuth2/OIDC + PKCE + refresh-rotation deployment is 6–7. SecureCom exceeds those on the data path (split pieces, piece signatures, multi-trust-domain isolation). Reaching a full 9 needs production hardening: mandatory mTLS, a real PKI, HSM/TPM keys, and Shamir threshold sharing instead of XOR split.

Download the solution

The complete SecureCom solution — source, samples, tools, certs, docker-compose and Aspire host — bundled as a single archive.

⬇ Download SecureCom.zip

Complete solution · .zip archive