Request Signing
Add an extra layer of security to your routes with cryptographic request signing. Verify that requests haven’t been tampered with and prevent replay attacks.What is Request Signing?
Request signing uses HMAC-SHA256 (Hash-based Message Authentication Code) to create a cryptographic signature of each request. This signature proves:- ✅ Authenticity: Request came from a trusted source
- ✅ Integrity: Request wasn’t modified in transit
- ✅ Non-repudiation: Sender cannot deny sending the request
Why Use Request Signing?
Without Request Signing
With Request Signing
How It Works
Signature Creation (Client Side)
- Combine request components:
- Create HMAC-SHA256 signature:
- Include in request headers:
Signature Verification (KnoxCall)
- Extract signature and timestamp from headers
- Recreate the message from request components
- Compute expected signature using shared secret
- Compare signatures:
- Match → Request is valid ✅
- Mismatch → Request is rejected ❌
Setting Up Request Signing
Step 1: Enable on Route
- Navigate to Routes → Select your route
- Scroll to Security section
- Toggle Require Signature to ON
- Configure settings:
- Click Save
Step 2: Create Signing Secret
- Navigate to Secrets → Add Secret
- Configure:
- Click Save
Step 3: Assign Secret to Client
- Navigate to Clients → Select your client
- Go to Signing Configuration tab
- Select the signing secret
- Click Save
Client Implementation
JavaScript/Node.js
Python
Go
PHP
Signature Verification Process
KnoxCall performs the following checks:1. Timestamp Validation
- Timestamp is more than 5 minutes old
- Timestamp is in the future (clock skew)
2. Signature Recreation
3. Signature Comparison
Preventing Replay Attacks
Request signing combined with timestamps prevents replay attacks:Nonce-Based Protection (Advanced)
For even stronger protection, add a nonce (number used once):Error Responses
Invalid Signature
Timestamp Too Old
Missing Headers
Best Practices
1. Use Strong Secrets
Generate cryptographically secure signing secrets:password123my-secret-key- Short or predictable strings
2. Rotate Secrets Regularly
Rotate signing secrets every 90 days:- Create new secret
- Update clients with new secret (gracefully)
- Support both old and new secrets for 24 hours
- Remove old secret
3. Use HTTPS Always
Request signing protects integrity, but not confidentiality:4. Include All Relevant Data
Sign everything that matters:5. Handle Clock Skew
Allow 5-minute tolerance for client clock differences:Use Cases
Payment Processing
Administrative Actions
Webhook Validation
High-Value Transactions
Troubleshooting
”Invalid signature” errors
Check:- ✓ Using the correct signing secret
- ✓ Message format matches exactly (order matters)
- ✓ Body is JSON-stringified identically
- ✓ No extra whitespace in headers
“Timestamp expired” errors
Causes:- Client clock is out of sync
- Request took too long to reach KnoxCall
- Network latency
- Sync client clock with NTP
- Increase timestamp tolerance (temporarily for testing)
- Reduce request queuing on client side
Signature works in test but not production
Check:- ✓ Using production signing secret (not test secret)
- ✓ Correct route configuration in production
- ✓ Client is assigned to production environment
Next Steps
Rate Limiting
Add rate limits for additional protection
Secret Management
Learn about managing signing secrets
Client Permissions
Configure client-level security
OAuth2 Flow
Set up OAuth2 authentication
📊 Statistics
- Level: advanced
- Time: 20 minutes
🏷️ Tags
security, hmac, signatures, authentication, integrity