-
Notifications
You must be signed in to change notification settings - Fork 161
Refresh Token SCIM Design Document
This design implements refresh token management capabilities for Janssen Server, providing users with visibility and control over applications that have been granted refresh tokens. The solution follows OAuth 2.0 and OpenID Connect best practices while integrating seamlessly with Janssen Server's existing architecture.
The design recommends implementing the feature through the Config API approach, as it aligns better with administrative token management functions and provides more flexibility for future enhancements.
graph TB
UI[User Interface] --> API[Config API Gateway]
API --> Auth[Authentication Service]
API --> TokenMgmt[Token Management Service]
TokenMgmt --> TokenStore[Token Storage]
TokenMgmt --> AuditLog[Audit Logging]
TokenMgmt --> Cache[Token Cache]
subgraph "Janssen Server Core"
Auth
TokenStore
AuditLog
end
Chosen Approach: Config API
Rationale:
- Config API is designed for administrative and management operations
- Better alignment with token lifecycle management functions
- More flexible authentication and authorization mechanisms
- Easier to extend for future administrative features
- Cleaner separation from user profile management (SCIM focus)
Purpose: Core business logic for refresh token operations
Key Methods:
public interface TokenManagementService {
List<RefreshTokenMetadata> getUserRefreshTokens(String userId);
boolean revokeRefreshToken(String userId, String tokenHash);
RefreshTokenMetadata getTokenMetadata(String tokenHash);
}Base Path: /jans-config-api/api/v1/token-management
- Purpose: Retrieve refresh token metadata for authenticated user
- Authentication: Bearer token (user's access token)
- Response: List of RefreshTokenMetadata objects
- Purpose: Revoke specific refresh token by hash
- Authentication: Bearer token (user's access token)
- Authorization: User must own the token
- Response: Success/failure confirmation
Purpose: Generate and validate token hashes for secure token identification
Key Methods:
public interface TokenHashService {
String generateTokenHash(String refreshToken);
boolean validateTokenHash(String refreshToken, String hash);
}Purpose: Log all token management operations for security monitoring
Events Logged:
- Token metadata requests
- Token revocation attempts (success/failure)
- Unauthorized access attempts
- Administrative operations
{
"tokenHash": "sha256_hash_of_token",
"clientId": "client_application_id",
"clientName": "Human Readable App Name",
"scopes": ["openid", "profile", "email"],
"issuedAt": "2025-01-15T10:30:00Z",
"lastUsed": "2025-01-20T14:22:00Z",
"expiresAt": "2025-04-15T10:30:00Z",
"deviceInfo": {
"userAgent": "Mozilla/5.0...",
"ipAddress": "192.168.1.100"
}
}{
"status": "success",
"data": [...],
"timestamp": "2025-01-20T15:30:00Z"
}{
"status": "error",
"error": {
"code": "TOKEN_NOT_FOUND",
"message": "The specified token hash was not found",
"details": "Token may have already been revoked or expired"
},
"timestamp": "2025-01-20T15:30:00Z"
}-
Authentication Errors (401)
- Invalid or expired access token
- Missing authentication header
-
Authorization Errors (403)
- User attempting to access tokens they don't own
- Insufficient permissions for operation
-
Not Found Errors (404)
- Token hash not found
- User has no refresh tokens
-
Validation Errors (400)
- Invalid token hash format
- Malformed request parameters
-
Server Errors (500)
- Database connection issues
- Internal service failures
- Consistent error response format across all endpoints
- Detailed error codes for programmatic handling
- User-friendly error messages
- Security-conscious error messages (no sensitive data exposure)
- Proper HTTP status codes
-
User Authentication
- Require valid access token for all operations
- Validate token signature and expiration
- Extract user identity from token claims
-
Authorization Controls
- Users can only access their own refresh tokens
- Implement proper scope validation
- Rate limiting on API endpoints
-
Token Hash Security
- Use SHA-256 for token hashing
- Include salt to prevent rainbow table attacks
- Store only hashed versions in responses
-
Sensitive Data Handling
- Never return actual refresh token values
- Limit metadata exposure to necessary fields
- Implement proper data retention policies
-
Audit Trail
- Log all access attempts and operations
- Include sufficient context for security analysis
- Implement log rotation and retention
-
Service Layer Tests
- Token management service operations
- Hash generation and validation
- Error handling scenarios
-
API Controller Tests
- Endpoint request/response handling
- Authentication and authorization
- Input validation
-
Database Integration
- Token storage and retrieval operations
- Transaction handling
- Connection pooling
-
External Service Integration
- Authentication service integration
- Audit logging integration
- Cache layer integration
-
Authentication Testing
- Invalid token scenarios
- Token expiration handling
- Cross-user access attempts
-
Authorization Testing
- Permission boundary validation
- Role-based access control
- Privilege escalation prevention
-
Load Testing
- High-volume token listing requests
- Concurrent revocation operations
- Database query performance
-
Stress Testing
- System behavior under extreme load
- Resource exhaustion scenarios
- Recovery mechanisms
New tables required:
-
refresh_token_metadata- Store token metadata and hashes -
token_audit_log- Audit trail for token operations
- Cache frequently accessed token metadata
- Implement cache invalidation on token revocation
- Use distributed cache for multi-instance deployments
- Metrics for API endpoint usage
- Performance monitoring for database queries
- Alert thresholds for unusual token activity
- Ensure existing refresh token functionality remains unchanged
- Gradual migration of existing tokens to include metadata
- Maintain API versioning for future enhancements