Currently, the JWT secret is hardcoded and cannot be rotated without invalidating all user sessions. We need to implement a secret rotation mechanism with the following requirements:
Requirements
Secret Persistence: Store multiple valid secrets in database with timestamps
Limited Expiration: Set reasonable JWT expiration (e.g., 30 minutes)
Retention Policy: Keep old secrets for 24-48 hours to allow graceful rotation
Rotation Mechanism: Admin endpoint to add new secrets and mark old ones for deletion
Validation Logic: Check tokens against all valid secrets, not just the current one
RotateSecret() (string, error) // Returns new secret
GetValidSecrets() ([]string, error)
CleanupExpiredSecrets()
JWT Validation Update:
Try all valid secrets when validating tokens
Log which secret was used for validation
Return specific error for expired tokens
Admin Endpoints:
POST /api/v1/admin/auth/secrets/rotate - Rotate current secret
GET /api/v1/admin/auth/secrets - List all valid secrets
DELETE /api/v1/admin/auth/secrets/{id} - Remove specific secret
Automatic Cleanup:
Background job to remove expired secrets
Log cleanup operations for audit trail
Security Considerations
Secret Storage: Hash secrets in database (bcrypt or similar)
Access Control: Only admins can rotate secrets
Audit Logging: Log all secret rotation operations
Rate Limiting: Prevent brute force attacks on rotation endpoint
Migration Path
Add new jwt_secrets table
Insert current secret as first entry
Update JWT validation to use secret service
Add admin endpoints
Implement cleanup job
Update documentation
Testing
Unit tests for secret service
Integration tests for JWT validation with multiple secrets
BDD scenarios for admin rotation workflow
Performance tests for validation with multiple secrets
References
ADR-0018: User Management and Authentication System
RFC 7519: JSON Web Token (JWT)
OWASP Authentication Cheat Sheet
Implement JWT Secret Rotation
Currently, the JWT secret is hardcoded and cannot be rotated without invalidating all user sessions. We need to implement a secret rotation mechanism with the following requirements:
## Requirements
1. **Secret Persistence**: Store multiple valid secrets in database with timestamps
2. **Limited Expiration**: Set reasonable JWT expiration (e.g., 30 minutes)
3. **Retention Policy**: Keep old secrets for 24-48 hours to allow graceful rotation
4. **Rotation Mechanism**: Admin endpoint to add new secrets and mark old ones for deletion
5. **Validation Logic**: Check tokens against all valid secrets, not just the current one
## Implementation Plan
1. **Database Schema**:
```sql
CREATE TABLE jwt_secrets (
id SERIAL PRIMARY KEY,
secret_hash VARCHAR(255) NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
expires_at TIMESTAMP WITH TIME ZONE,
is_active BOOLEAN DEFAULT TRUE
);
```
2. **Secret Management Service**:
- AddSecret(secret string, expiration time.Duration)
- RotateSecret() (string, error) // Returns new secret
- GetValidSecrets() ([]string, error)
- CleanupExpiredSecrets()
3. **JWT Validation Update**:
- Try all valid secrets when validating tokens
- Log which secret was used for validation
- Return specific error for expired tokens
4. **Admin Endpoints**:
- POST /api/v1/admin/auth/secrets/rotate - Rotate current secret
- GET /api/v1/admin/auth/secrets - List all valid secrets
- DELETE /api/v1/admin/auth/secrets/{id} - Remove specific secret
5. **Automatic Cleanup**:
- Background job to remove expired secrets
- Log cleanup operations for audit trail
## Security Considerations
1. **Secret Storage**: Hash secrets in database (bcrypt or similar)
2. **Access Control**: Only admins can rotate secrets
3. **Audit Logging**: Log all secret rotation operations
4. **Rate Limiting**: Prevent brute force attacks on rotation endpoint
## Migration Path
1. Add new jwt_secrets table
2. Insert current secret as first entry
3. Update JWT validation to use secret service
4. Add admin endpoints
5. Implement cleanup job
6. Update documentation
## Testing
- Unit tests for secret service
- Integration tests for JWT validation with multiple secrets
- BDD scenarios for admin rotation workflow
- Performance tests for validation with multiple secrets
## References
- ADR-0018: User Management and Authentication System
- RFC 7519: JSON Web Token (JWT)
- OWASP Authentication Cheat Sheet
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Implement JWT Secret Rotation
Currently, the JWT secret is hardcoded and cannot be rotated without invalidating all user sessions. We need to implement a secret rotation mechanism with the following requirements:
Requirements
Implementation Plan
Database Schema:
Secret Management Service:
JWT Validation Update:
Admin Endpoints:
Automatic Cleanup:
Security Considerations
Migration Path
Testing
References
📊 SOLID Analysis Complete
I've completed a comprehensive SOLID principles and best practices review of the codebase. Here are the key findings:
Critical Issues Found
Major Issues Found
Recommendations
High Priority Refactoring
Medium Priority Improvements
Low Priority Cleanup
Cognitive Complexity Analysis
The current implementation shows:
After refactoring, we should see:
Next Steps
I recommend we:
This will significantly reduce cognitive load while maintaining all functionality.