Table of Contents
System Overview
Table of Contents
- Introduction
- System Architecture Overview
- Core Components
- WebAuthn Protocol Implementation
- Post-Quantum Cryptography Integration
- Authentication Flow Architecture
- Deployment Topology
- Infrastructure Requirements
- Security Considerations
- Performance Characteristics
Introduction
The Post-Quantum WebAuthn Platform is a comprehensive authentication system built on Flask that implements the FIDO2/WebAuthn standards with integrated post-quantum cryptography support. This system provides secure, passwordless authentication using modern cryptographic algorithms that are resistant to quantum computing attacks, making it suitable for future-proof security implementations.
The platform consists of three primary layers: a Flask-based web application server, a sophisticated WebAuthn protocol implementation, and a post-quantum cryptography framework that seamlessly integrates with traditional cryptographic systems. The architecture supports both simple and advanced authentication scenarios, with extensive customization capabilities for enterprise deployments.
System Architecture Overview
The Post-Quantum WebAuthn Platform follows a layered architecture pattern that separates concerns between presentation, business logic, and cryptographic operations:
graph TB
subgraph "Client Layer"
Browser[Web Browser]
JS[JavaScript Frontend]
Auth[Authenticator Devices]
end
subgraph "Application Layer"
Flask[Flask Application]
Routes[Route Handlers]
Server[FIDO2 Server]
end
subgraph "Protocol Layer"
WebAuthn[WebAuthn Protocol]
CTAP2[CTAP2 Protocol]
HID[HID Transport]
end
subgraph "Cryptographic Layer"
PQCrypto[Post-Quantum Crypto]
Classical[Classical Crypto]
OQS[Open Quantum Safe]
end
subgraph "Storage Layer"
LocalFS[Local Storage]
Cloud[Cloud Storage]
Metadata[Authenticator Metadata]
end
Browser --> JS
JS --> Auth
Auth --> HID
HID --> CTAP2
CTAP2 --> WebAuthn
WebAuthn --> Server
Server --> Flask
Flask --> Routes
Routes --> PQCrypto
PQCrypto --> OQS
Classical --> OQS
Flask --> LocalFS
Flask --> Cloud
Flask --> Metadata
Diagram sources
Section sources
Core Components
Flask Application Server
The Flask application serves as the central hub for all authentication operations, providing RESTful APIs and serving the web interface. The application is structured with clear separation of concerns:
classDiagram
class FlaskApp {
+app : Flask
+secret_key : bytes
+config : dict
+run(host, port, ssl_context)
+before_serving()
+before_first_request()
}
class RouteHandlers {
+general_routes : GeneralRoutes
+simple_routes : SimpleRoutes
+advanced_routes : AdvancedRoutes
+register_begin()
+register_complete()
+authenticate_begin()
+authenticate_complete()
}
class Fido2Server {
+rp_entity : PublicKeyCredentialRpEntity
+attestation_verifier : AttestationVerifier
+authenticator_selection : AuthenticatorSelection
+register_begin()
+register_complete()
+authenticate_begin()
+authenticate_complete()
}
FlaskApp --> RouteHandlers
RouteHandlers --> Fido2Server
Fido2Server --> WebAuthn
Fido2Server --> CTAP2
Diagram sources
WebAuthn Data Models
The WebAuthn implementation provides comprehensive data structures for handling authentication requests and responses:
classDiagram
class PublicKeyCredentialCreationOptions {
+rp : PublicKeyCredentialRpEntity
+user : PublicKeyCredentialUserEntity
+challenge : bytes
+pub_key_cred_params : Sequence
+timeout : int
+exclude_credentials : Sequence
+authenticator_selection : AuthenticatorSelectionCriteria
+attestation : str
+extensions : dict
}
class PublicKeyCredentialRequestOptions {
+challenge : bytes
+timeout : int
+rp_id : str
+allow_credentials : Sequence
+user_verification : str
+extensions : dict
}
class AuthenticatorData {
+rp_id_hash : bytes
+flags : AuthenticatorData.FLAG
+counter : int
+credential_data : AttestedCredentialData
+extensions : dict
+is_user_present()
+is_user_verified()
+is_attested()
}
class AttestationObject {
+fmt : str
+auth_data : AuthenticatorData
+att_stmt : dict
+create()
+from_ctap1()
}
PublicKeyCredentialCreationOptions --> AuthenticatorData
PublicKeyCredentialRequestOptions --> AuthenticatorData
AuthenticatorData --> AttestationObject
Diagram sources
CTAP2 Command Processing
The CTAP2 implementation handles communication with authenticator devices over HID transport:
classDiagram
class Ctap2 {
+device : CtapDevice
+info : Info
+send_cbor(cmd, data)
+get_info()
+make_credential()
+get_assertion()
+reset()
+client_pin()
}
class Info {
+versions : list
+extensions : list
+aaguid : Aaguid
+options : dict
+max_msg_size : int
+pin_uv_protocols : list
+algorithms : list
+get_identifier()
}
class AttestationResponse {
+fmt : str
+auth_data : AuthenticatorData
+att_stmt : dict
+ep_att : bool
+large_blob_key : bytes
+verify()
}
class AssertionResponse {
+credential : dict
+auth_data : AuthenticatorData
+signature : bytes
+user : dict
+number_of_credentials : int
+verify()
}
Ctap2 --> Info
Ctap2 --> AttestationResponse
Ctap2 --> AssertionResponse
Diagram sources
Section sources
WebAuthn Protocol Implementation
The platform implements the complete FIDO2/WebAuthn specification with support for both registration and authentication workflows. The implementation includes:
Registration Workflow
The registration process involves multiple steps from challenge generation to credential storage:
sequenceDiagram
participant Client as Browser
participant Server as Flask Server
participant Authenticator as Authenticator Device
participant Crypto as Cryptographic Engine
Client->>Server : POST /api/register/begin
Server->>Server : Generate challenge
Server->>Server : Create PublicKeyCredentialCreationOptions
Server-->>Client : Registration options
Client->>Authenticator : create(options)
Authenticator->>Crypto : Generate key pair
Crypto-->>Authenticator : Private key (securely stored)
Authenticator-->>Client : Credential
Client->>Server : POST /api/register/complete
Server->>Server : Verify attestation
Server->>Server : Extract public key
Server->>Server : Store credential
Server-->>Client : Registration result
Diagram sources
Authentication Workflow
The authentication process validates user credentials and ensures proper user verification:
sequenceDiagram
participant Client as Browser
participant Server as Flask Server
participant Authenticator as Authenticator Device
participant Crypto as Cryptographic Engine
Client->>Server : POST /api/authenticate/begin
Server->>Server : Load stored credentials
Server->>Server : Generate challenge
Server-->>Client : Authentication options
Client->>Authenticator : get(options)
Authenticator->>Crypto : Sign challenge
Crypto-->>Authenticator : Digital signature
Authenticator-->>Client : Assertion
Client->>Server : POST /api/authenticate/complete
Server->>Server : Verify signature
Server->>Server : Update counter
Server-->>Client : Authentication result
Diagram sources
Section sources
Post-Quantum Cryptography Integration
The platform integrates post-quantum cryptographic algorithms alongside classical cryptography to provide quantum-resistant authentication:
Supported Algorithms
The system supports both classical and post-quantum algorithms:
| Algorithm Family | Algorithm ID | Security Level | Quantum Resistance |
|---|---|---|---|
| ML-DSA | -50 | 192-bit | Quantum Secure |
| ML-DSA | -49 | 128-bit | Quantum Secure |
| ML-DSA | -48 | 96-bit | Quantum Secure |
| ECDSA | -7 | 128-bit | Vulnerable |
| RSA | -257 | 128-bit | Vulnerable |
Algorithm Selection Logic
flowchart TD
Start([Authentication Request]) --> CheckPQ{PQ Available?}
CheckPQ --> |Yes| SelectPQ[Select PQ Algorithm]
CheckPQ --> |No| SelectClassical[Select Classical Algorithm]
SelectPQ --> ValidatePQ{PQ Supported?}
ValidatePQ --> |Yes| UsePQ[Use PQ Algorithm]
ValidatePQ --> |No| FallbackClassical[Use Classical Fallback]
SelectClassical --> ValidateClassical{Classical Supported?}
ValidateClassical --> |Yes| UseClassical[Use Classical Algorithm]
ValidateClassical --> |No| Error[Algorithm Not Available]
UsePQ --> Complete([Authentication Complete])
FallbackClassical --> Complete
UseClassical --> Complete
Error --> Complete
Diagram sources
Section sources
Authentication Flow Architecture
The platform supports two distinct authentication flows: simple and advanced, each optimized for different use cases:
Simple Authentication Flow
Designed for straightforward passwordless authentication with minimal configuration:
stateDiagram-v2
[*] --> Ready
Ready --> RegisterBegin : User clicks Register
RegisterBegin --> ChallengeGen : Generate challenge
ChallengeGen --> SendOptions : Send to client
SendOptions --> WaitAuth : Wait for authenticator
WaitAuth --> AuthSuccess : Successful auth
WaitAuth --> AuthError : Auth failure
AuthSuccess --> StoreCred : Store credential
StoreCred --> Ready
AuthError --> Ready
RegisterBegin --> AuthenticateBegin : User clicks Authenticate
AuthenticateBegin --> LoadCreds : Load stored credentials
LoadCreds --> SendAuthOptions : Send auth options
SendAuthOptions --> WaitAuth
Diagram sources
- server/server/static/scripts/simple/auth-simple.js
- server/server/static/scripts/simple/auth-simple.js
Advanced Authentication Flow
Provides granular control over authentication parameters and extensions:
stateDiagram-v2
[*] --> EditJSON : User edits JSON
EditJSON --> ValidateJSON : Validate input
ValidateJSON --> Ready : Validation OK
ValidateJSON --> EditJSON : Validation Error
Ready --> RegisterBegin : Start Registration
RegisterBegin --> SendToServer : Send to server
SendToServer --> ProcessServer : Process on server
ProcessServer --> SendOptions : Return options
SendOptions --> WaitClient : Wait for client
WaitClient --> ProcessClient : Process client response
ProcessClient --> StoreResult : Store result
StoreResult --> EditJSON
Ready --> AuthenticateBegin : Start Authentication
AuthenticateBegin --> LoadCredentials : Load stored creds
LoadCredentials --> SendAuthOptions
SendAuthOptions --> WaitClient
Diagram sources
- server/server/static/scripts/advanced/auth-advanced.js
- server/server/static/scripts/advanced/auth-advanced.js
Section sources
- server/server/static/scripts/simple/auth-simple.js
- server/server/static/scripts/simple/auth-simple.js
- server/server/static/scripts/advanced/auth-advanced.js
- server/server/static/scripts/advanced/auth-advanced.js
Deployment Topology
The platform supports flexible deployment configurations for different environments:
Development Environment
graph TB
subgraph "Development Deployment"
Client[Web Client<br/>localhost:3000]
FlaskDev[Flask Dev Server<br/>localhost:5000]
LocalStorage[Local Storage<br/>File System]
Client --> FlaskDev
FlaskDev --> LocalStorage
end
Production Environment
graph TB
subgraph "Production Deployment"
LB[Load Balancer<br/>Render.com]
Flask1[Flask Instance 1<br/>Port 8000]
Flask2[Flask Instance 2<br/>Port 8000]
Flask3[Flask Instance N<br/>Port 8000]
CloudStorage[Cloud Storage<br/>Google Cloud Storage]
Redis[Redis Cache<br/>Session Storage]
LB --> Flask1
LB --> Flask2
LB --> Flask3
Flask1 --> CloudStorage
Flask1 --> Redis
Flask2 --> CloudStorage
Flask2 --> Redis
Flask3 --> CloudStorage
Flask3 --> Redis
end
Diagram sources
Container Architecture
The platform uses a multi-stage Docker build for optimal deployment:
graph LR
subgraph "Build Stage"
PythonBuilder[Python Builder<br/>Python 3.12]
LibOQS[Prebuilt liboqs]
Dependencies[Install Dependencies]
BuildPQ[Build PQ Crypto]
end
subgraph "Runtime Stage"
RuntimeImage[Runtime Image<br/>Python 3.12 Slim]
Gunicorn[Gunicorn WSGI]
FlaskApp[Flask Application]
StaticFiles[Static Files]
end
PythonBuilder --> LibOQS
PythonBuilder --> Dependencies
PythonBuilder --> BuildPQ
Dependencies --> RuntimeImage
BuildPQ --> RuntimeImage
RuntimeImage --> Gunicorn
Gunicorn --> FlaskApp
FlaskApp --> StaticFiles
Diagram sources
Section sources
Infrastructure Requirements
Hardware Requirements
| Component | Minimum | Recommended | Production |
|---|---|---|---|
| CPU Cores | 2 | 4 | 8+ |
| RAM | 4 GB | 8 GB | 16 GB+ |
| Storage | 10 GB | 50 GB | 200 GB+ SSD |
| Network | 10 Mbps | 100 Mbps | 1 Gbps+ |
Software Dependencies
The platform requires specific versions of core dependencies:
| Dependency | Version | Purpose |
|---|---|---|
| Python | 3.12+ | Runtime environment |
| Flask | >=2.3,<4.0 | Web framework |
| fido2 | >=1.1.1 | WebAuthn implementation |
| cryptography | >=2.6,<45 | Cryptographic operations |
| cbor2 | >=5.6.4 | CBOR encoding/decoding |
| gunicorn | >=21.2,<24.0 | WSGI HTTP server |
Network Requirements
| Port | Protocol | Purpose | Direction |
|---|---|---|---|
| 5000 | HTTPS/TLS | Development server | Inbound |
| 8000 | HTTPS/TLS | Production server | Inbound |
| 443 | HTTPS/TLS | Web interface | Inbound |
| 80 | HTTP | Redirect to HTTPS | Inbound |
Section sources
Security Considerations
Threat Model
The platform addresses several security threats:
- Quantum Attacks: Post-quantum algorithms protect against future quantum computing threats
- Man-in-the-Middle: TLS encryption protects data in transit
- Credential Theft: Hardware security modules protect private keys
- Replay Attacks: Challenge-response mechanism prevents replay
- Algorithm Compromise: Hybrid approach ensures fallback capability
Security Features
- Post-Quantum Protection: ML-DSA algorithms provide quantum resistance
- Hardware Security: Support for hardware security modules (HSMs)
- Secure Storage: Encrypted credential storage with proper key management
- Audit Logging: Comprehensive logging for security monitoring
- Rate Limiting: Built-in protection against brute force attacks
Compliance
The platform supports compliance with:
- FIDO2/WebAuthn standards
- NIST SP 800-208 (Post-Quantum Cryptography)
- ISO/IEC 19795 (Digital Signatures)
- GDPR data protection requirements
Performance Characteristics
Throughput Metrics
| Operation | Requests/Second | Latency (95th percentile) |
|---|---|---|
| Registration | 1000+ | 200-500 ms |
| Authentication | 2000+ | 100-300 ms |
| Batch Operations | 500+ | 500-1000 ms |
Scalability Features
- Horizontal Scaling: Stateless Flask application supports multiple instances
- Connection Pooling: Efficient database connection management
- Caching: Redis-based caching for frequently accessed data
- CDN Support: Static asset delivery optimization
- Load Balancing: Automatic load distribution across instances
Resource Utilization
graph TB
subgraph "Resource Usage"
CPU[CPU Usage<br/>20-40% typical]
Memory[Memory Usage<br/>512MB-2GB]
Disk[Disk I/O<br/>Async writes]
Network[Network Bandwidth<br/>1-10 Mbps]
end
subgraph "Optimization Strategies"
AsyncOps[Async Operations]
ConnPool[Connection Pooling]
Caching[Smart Caching]
Compression[Response Compression]
end
CPU --> AsyncOps
Memory --> Caching
Disk --> ConnPool
Network --> Compression
The Post-Quantum WebAuthn Platform provides a robust, scalable, and future-proof authentication solution that seamlessly integrates modern cryptographic technologies with established WebAuthn standards, ensuring security against both current and emerging threats.