Known Limitations

This page documents known limitations and considerations when deploying AuthProxy.

Browser Compatibility

WebCrypto API

AuthProxy requires WebCrypto API support for client-side cryptographic operations:

• Required for: Challenge signing, key generation
• Supported: All modern browsers (Chrome 37+, Firefox 34+, Safari 11+, Edge 12+)
• Not supported: IE11, older mobile browsers

Web Push API

Push notification support varies by browser:

Browser	Support	Notes
Chrome	Full	All platforms
Firefox	Full	All platforms
Safari	Partial	macOS only, iOS 16.4+
Edge	Full	All platforms

iOS Safari limitation: Web Push requires iOS 16.4+ and PWA installation.

Transport limitation:

• browser Web Push still depends on the browser vendor push service (for example Chrome/Edge endpoints, Firefox autopush, Safari/APNs integration)
• AuthProxy owns subscription storage and payload delivery logic, but it does not replace the browser infrastructure that wakes the service worker
• live UI refresh still requires SSE; Web Push is the background channel
• a closed tab is a valid Web Push target, but a fully terminated browser process may still prevent delivery on some desktop/browser configurations
• if the browser exposes a "continue running background apps" or similar option, disabling it can stop Web Push wakeups even when AuthProxy delivery is correct

Deployment limitation in phase 1:

• only one AuthProxy node should have PushSending enabled in a multi-proxy cluster
• this avoids duplicate push delivery while the platform still uses the simpler single-sender model
• future releases may replace this with distributed claim/outbox coordination

FIDO2/WebAuthn

Hardware key support depends on browser and OS:

Platform	Support	Notes
Desktop Chrome/Firefox/Edge	Full	USB, NFC, Bluetooth keys
Desktop Safari	Full	Touch ID, USB keys
Android Chrome	Full	Fingerprint, USB keys
iOS Safari	Partial	Face ID/Touch ID only, no USB

Scaling Considerations

Session Locality

AuthProxy uses session locality (sessions bound to specific proxy instance):

Benefits:

• No shared state infrastructure needed
• No Redis/Memcached dependency
• Simple horizontal scaling

Limitations:

• User must reconnect if proxy instance restarts
• Load balancer sticky sessions not required but instance failover causes re-auth

Load Balancer Configuration

When using multiple instances behind a load balancer:

• Sticky sessions: Not required (session locality handles this)
• Health checks: Use /health endpoint
• SSL termination: Supported at load balancer level

File Storage

Supported Backends

Current file storage supports:

• local disk via LocalFileStoragePath
• external HTTP file servers via FileServers

Limitations:

• LocalFileStoragePath ties file bytes to the current AuthProxy instance unless you add shared storage outside AuthProxy.
• External HTTP storage adds network latency to upload/download paths.
• No built-in object storage or CDN integration.

Recommendation:

• For mono-proxy or other single-instance deployments, prefer LocalFileStoragePath.
• For multi-node or externally managed storage, use an HTTP storage backend designed for AuthProxy.
• Use CDN only for static public assets, not as a replacement for AuthProxy attachment metadata flow.

Cross-Domain Sessions

Single Domain by Default

Sessions cannot be shared across different domains without additional configuration:

• Session cookie bound to specific domain
• AuthProxy instances for different domains are independent

Solution: Use app_login / app_access for cross-domain authentication. Federation v2 is for partner app trust and payment/webhook flows, not for generic shared sessions.

Database Specific

SQLite Limitations

When using SQLite (standalone mode):

• No concurrent write support (single writer)
• Not suitable for high-traffic production
• No TVP (Table-Valued Parameters) support
• Limited to single-node deployment

Use case: Development, edge deployment, low-traffic sites.

PostgreSQL Limitations

When using PostgreSQL:

• No rowversion equivalent (use alternative concurrency control)
• No TVP support (use UNNEST for batch operations)
• Different datetime handling

Use case: Open source deployments, PostgreSQL-only environments.

Rate Limiting

Aggressive Defaults

Default rate limiting may be too aggressive for some use cases:

• Per IP: 100 requests/minute (default)
• Per Session: 1000 requests/minute (default)

Solution: Adjust via settings table or configuration.

Test Environment

Rate limiting can cause issues in automated testing:

• Multiple rapid requests trigger limits
• E2E tests may see 429 responses

Solution: Increase limits or disable for Test environment.

Performance

Memory Usage

File caching consumes memory:

• All static files cached in memory by default
• Large wwwroot folders increase memory footprint

Recommendation: Monitor memory usage, consider external CDN for large static assets.

Cold Start

First request after startup may be slower:

• Database connection initialization
• Route configuration loading
• File cache warming

Mitigation: Health check endpoints, graceful deployment.

Integration

OAuth Provider Dependencies

External OAuth providers introduce dependencies:

Provider	Dependency
Google	Google API availability
Telegram	Telegram Bot API availability
Discord	Discord API availability
GitHub	GitHub API availability
VK	VK API availability

Recommendation: Implement fallback authentication methods.

Module Communication

Inter-module communication requires:

• All modules accessible via HTTP
• API keys configured correctly
• Network connectivity between services

Planned Improvements

These limitations are being addressed in future releases:

• S3/Azure Blob storage backend for files
• Built-in CDN integration
• Cross-domain session federation improvements
• Improved SQLite concurrency
• Configurable rate limiting per route