Optimizing your OpenID Connect (OIDC) integration is key to delivering fast, secure, and scalable authentication experiences. By thoughtfully managing identity mappings, applying throttling, and designing for scalability, you can ensure that your OIDC implementations remain resilient and efficient even as user demand grows, and ensure optimal performance and stability of the JFrog Platform Deployment (JPD).
Environment and Resource Context
The following recommendations were created by conducting performance testing on the Access service in a new, large environment with the following resources:
3 pods of each service
Limits for each Access service container:
CPU limit: 6 cores
Memory limit: 3 GB
Note that different instances might have different performance capabilities.
The OIDC system demonstrates strong reliability at moderate load levels. To effectively scale your OIDC integration and avoid issues, use the following best practices:
Optimize Identity Mappings
Efficient identity mappings are essential for maintaining low latency and predictable performance. To optimize identity mappings:
Keep claims small and simple: Avoid elements like wildcards (*) that increase processing overhead.
Prioritize critical mappings: Place the most frequently used mappings higher in the list to reduce search depth, resources, and evaluation time.
Control Load and Concurrency
A high number of concurrent operations causes stress on the system. To control your load:
Keep identity mapping creation/edit rate below 500 requests per second: To maintain consistent performance and prevent overload, use throttling or scheduled updates when approaching 1000 requests per second.
Keep token exchange rate below 40 requests per second: Use throttling or scheduled updates when exceeding this threshold.
Plan for Scale and Resilience
To ensure scalability and fault tolerance under varying workloads:
Segment mappings: To avoid massive, monolithic mapping lists that slow down processing, separate mapping lists by different projects or teams.
Enable auto-scaling and proactive monitoring: Monitor for error spikes (specifically 409, 502, or 503 errors) as early indicators of resource strain or contention.
In summary, to maintain stability under higher concurrency, optimize mappings, enforce throttling, and design for horizontal scalability for smooth and scalable performance.