OIDC performance benchmarks
The Boundary engineering team conducted benchmark testing across large managed group deployments to validate OIDC performance and measure authentication latency under increasing scale. Testing evaluated both new user logins and existing logins from returning users.
The results provide guidance on expected authentication performance and recommended operating ranges.
Scope
The tests addressed the following questions:
- How does OIDC login latency scale as the number of managed groups increases?
- What is the expected difference between first time and returning user logins?
- What factors contribute most to authentication latency?
- What deployment and configuration practices improve performance?
Environment
The test environment was an HCP Boundary v1.0.1 cluster with two workers and two controllers:
| CPU | Memory | Maximum memory | |
|---|---|---|---|
| Controllers | 2048 MHz | 2048 MB | 4096 MB |
| Workers | 512 MHz | 1024 MB | 2048 MB |
The maximum memory was configured to accommodate burst workloads.
Database sizing was not a significant factor for the tests. The database load primarily comes from changes to managed group memberships. That load scales linearly with the number of membership changes.
Methodology
Engineers conducted the OIDC performance benchmark testing using:
- KeyCloak as the OIDC provider
- Five synthetic users per scenario, each with an OIDC token containing 100 groups
- Sequential authentication requests
- Non-redundant, synthetic managed group filters
- Increasing managed group counts to measure scalability
They tested two authentication scenarios:
New user login: Boundary evaluates all managed group filters, determines group membership, and creates membership records.
Existing user login: Boundary evaluates all managed group filters and confirms no changes to the existing membership records.
Results
The following table shows latency results by managed group configuration:
| Number of managed groups | New user login time | Existing user login time | Recommendation |
|---|---|---|---|
| 20,000 | 34.1 seconds | 7.94 seconds | Recommended operating range |
| 25,000 | 49.5 seconds | 16.2 seconds | Supported for larger deployments |
| 30,000 | Partial completion with failures | 10.97 seconds | Beyond recommended operating range |
At 30,000 managed groups, some new user logins failed to complete.
These measurements reflect controlled benchmark conditions. Actual production latency depends on deployment characteristics, user membership patterns, and the complexity of managed group filters.
Findings
The benchmark demonstrates the following characteristics of Boundary authentication:
Managed group count influences login latency: Authentication work increases as the number of managed groups increases because Boundary must evaluate additional filters at login.
New user onboarding is resource intensive: The initial user authentication requires Boundary to evaluate all managed group filters and create membership records, which takes longer than subsequent logins.
Filter complexity impacts performance: Authentication performance depends not only on the number of managed groups, but also on the complexity of filters. Simple filters reduce the amount of evaluation required and reduce authentication latency.
Best practices
The benchmark establishes a practical baseline for large managed group deployments.
Organizations that expect managed group count to grow should observe the following best practices to prevent performance issues as your deployment scales:
Remove unused managed groups: Boundary evaluates all managed groups during authentication, including unused ones. Periodically auditing and removing unused managed groups reduces unnecessary evaluation.
Simplify managed group filters: Avoid unnecessary or redundant filter clauses. Simple filters reduce the time required for evaluation.
Standardize filter templates: Using consistent managed group templates simplifies maintenance and provides more predictable performance.
Review configurations periodically: As deployments grow, periodically review managed group count, filter complexity, and unused configurations to prevent latency from becoming a problem.
By planning for capacity proactively, you can avoid unexpected authentication latency.
More information
Refer to Filter managed groups for more information about creating filters for OIDC managed groups.