How QuantumAuth Works
QuantumAuth replaces traditional authentication and wallet models with device-bound identity rooted in secure hardware.
Users authenticate once on their own device using the QuantumAuth Client.
After that, applications and Web3 dApps can securely authenticate users and authorize actions without passwords, tokens, browser wallets, or seed phrases.
Authentication and signing become invisible.
High-Level Flow
QuantumAuth is built around three components:
- QuantumAuth Client (local, trusted)
- QuantumAuth Browser Extension (bridge, no keys)
- QuantumAuth Server + SDK (verification layer)
All cryptographic operations happen on the user’s device, never in the browser or the application.
Device-Bound Identity
QuantumAuth anchors identity directly to the device:
- A TPM-backed keypair is generated locally
- The private key is sealed inside the TPM
- The key cannot be copied, exported, or exfiltrated
- All authentication and signing operations happen locally
The QuantumAuth Server stores only the public key and device metadata.
This creates a hardware-rooted identity that cannot be phished or reused elsewhere.
Because identity is device-bound:
- No passwords are needed
- No secrets live in apps or browsers
- No tokens are issued or refreshed
- Replay attacks are prevented by challenge signing
One-Time Local Login
Users authenticate once via the QuantumAuth Client.
After this initial setup:
- The device is trusted by QuantumAuth
- The Client can sign authentication and wallet requests
- Applications never see credentials or keys
There is no per-app login flow.
Authentication Flow (Apps & APIs)
When an application needs to authenticate a user action:
1. The frontend requests authentication from the local client
GET http://localhost:8090/qa/authenticate
The QuantumAuth Client returns:
- A TPM-signed challenge
- A post-quantum signature
- Canonical request metadata
2. The frontend forwards the proof to its backend
POST /api/action
Authorization: QuantumAuth ...
X-QuantumAuth-Canonical-B64: ...
3. The backend validates via the QuantumAuth SDK
The SDK middleware:
- Extracts the proof
- Canonicalizes the request
- Forwards everything to the QuantumAuth Server
4. The QuantumAuth Server verifies the request
The server validates:
- TPM signature (hardware-rooted identity)
- Post-quantum signature
- One-time challenge (freshness / replay protection)
- Device ↔ user binding
If valid, it returns:
{
"userId": "024e6efd-471d-4848-8fba-0d2ad74e2b68"
}
5. The backend proceeds as authenticated
No sessions.
No tokens.
No password checks.
Wallet Architecture (No Browser Wallet)
QuantumAuth includes a hardware-secured wallet that follows the same model:
- Wallet keys are TPM-sealed
- No seed phrases
- No private keys in browser memory
- No wallet managing secrets in JavaScript
All signing happens inside the QuantumAuth Client.
The Browser Extension (Secure Bridge)
The QuantumAuth browser extension is not a wallet.
It does not:
- Store keys
- Generate signatures
- Hold secrets
Its role is strictly to:
- Bridge Web3 requests from the browser to the local QuantumAuth Client
- Enforce origin and request integrity
- Prevent direct access to cryptographic material
This removes the browser as a trust boundary.
Web3 & Account Abstraction
QuantumAuth wallets are designed for Account Abstraction (ERC-4337):
- Smart accounts with programmable security policies
- Hardware-backed signatures
- Multi-factor and recovery logic
- Policy-based execution for high-risk actions
QuantumAuth exposes a standard EIP-1193 provider, so existing dApps work without modification — while gaining significantly stronger security.
What This Architecture Achieves
- Passwordless authentication
- Hardware-rooted identity
- Wallets without seed phrases
- No private keys in browsers
- Invisible auth UX
- Minimal integration for developers
- Strong guarantees against phishing and key theft