Open CangPham opened 3 weeks ago
Can you please tell us more about the scenario you're in? How does changing IdentityServer's URI affect the ClientRedirectUris/ClientPostLogoutRedirectUris? Having a client with so many redirect uris is not something we recommend also from a security standpoint.
Hi @RolandGuijt ,
In our scenario, every time the company releases a new version of the software, we clone a virtual machine that installs the software with a name that includes the software name and version for better management.
Step by step:
Version Release: For each new version release, we clone the virtual machine, giving it a unique name like gfdevsuite2020, gfdevsuite2021, etc. Development Mode: In development, each developer works on a machine with a different name, but all machines share the same database. Impact on Redirect URIs: As a result, we end up with many redirect URIs in the ClientRedirectUris and ClientPostLogoutRedirectUris tables for a single client because the client is used across multiple machine instances, each with a different URI.
The Linq query that retrieves clients has been optimized in 6.0.4. Can you please upgrade to the latest 6.0 version, 6.0.5 and see if the problem persists? You should be able to upgrade without doing any migrations or modifications. We recommend you update to the latest 6 version 6.3.10 as soon as possible as it fixes security-related issues too. But that would require migrations and possibly modifications. Please see our upgrade guide.
Which version of Duende IdentityServer are you using?
Which version of .NET are you using?
Describe the bug
Summary: We've encountered significant performance degradation in our IdentityServer instance during the login process, especially when redirecting back to the client. This issue seems to stem from database inefficiencies, particularly when handling clients with a large number of redirect URIs.
Detailed Description: While analyzing the logs and performance during the login process, we observed the following:
Slow Redirects:
The issue occurs when attempting to log in to IdentityServer, resulting in a very long wait time when redirecting back to the client. The delay exceeds 11 seconds when there are more than 100 redirect URIs associated with a single client. Log Analysis:
The log file shows a 4-second delay, even though the query execution is reported to take only 4 ms:
Manually executing the same query returns 50,000 rows and takes 4 seconds, indicating a potential issue with the Identity database.
Our database contains a large number of different ClientRedirectUris and ClientPostLogoutRedirectUris that share the same clientId. This results in the query returning a significant number of rows, contributing to the observed performance issues.
In particular, the problem becomes severe when the client has more than 100 redirect URIs, causing the login process to take over 11 seconds to complete the redirect.
To Reproduce
Seed Data:
We have a function that seeds data every time a new version is installed. During development, we change the URI of IdentityServer according to the current version for easier tracking (e.g., gfdevsuite2020, gfdevsuite2021, etc.). Development Process:
As a result of these URI changes, multiple entries are created in the ClientRedirectUris and ClientPostLogoutRedirectUris tables with different URIs but the same clientId. Login Attempt:
Attempt to log in to IdentityServer with a client that has more than 100 redirect URIs associated with it. Observe the delay in redirecting back to the client, which can exceed 11 seconds.
Expected behavior
Database Performance:
Request for Assistance:
FYI https://github.com/cakkermans @cakkermans