Closed pmbaokhanh closed 1 month ago
This seems to be a data protection issue. Can you please follow our written guide about that and let us know if the tips in there helped?
Thanks for your reply. I looked at the guide. We are almost doing what is recommended. However, there is one thing stand out for us that is:
services.AddDataProtection()
.PersistKeysToStackExchangeRedis(() => multiplexer.GetDatabase().WithKeyPrefix(redisPrefix), RedisDataProtectionKey);
WORKDIR /home/site/wwwroot
to WORKDIR /app
Do you think that is what could cause this issue?
And if it is what is causing the issue. Does it mean that the issue should resolve itself after all of our user re-login? If I apply the application name now, it will cause another wave of forcing user to login right? Considering the deployment was out for about 1 week. For application name, will simply set it as "IdentityServer" work, or I have to use the path like this guide https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-6.0#setapplicationname
Thanks Roland
Yes, I think that is the issue. Data protection prevents apps from accessing each others encrypted data by using a string value to discriminate. If an application name isn't set it will use the content root path to construct it.
IdentityServer relies heavily on the data protection feature. All grants e.g. are encrypted with it. So when the string is changed the current values for the application won't be readable anymore. That doesn't necessarily mean that all current sessions are ended on the spot. If clients are using a self-contained cookie, i.e. if the server side sessions feature of IdentityServer isn't active, the session will continue as long as the cookie is valid and there is no interaction with the identity provider (like refreshing access tokens).
I would set the value to a static string that uniquely identifies the application. Maybe something like "[companyname]-identityprovider".
Thanks a not for your confirmation Roland. I will close this issue.
Which version of Duende IdentityServer are you using? Duende 6.1.5 Which version of .NET are you using? 6.0 Describe the bug
We have our Duende identity server running in k8s with 2 instances. Recently, after a deployment, we suddenly hit exceptions when clients try to refresh tokens with below stack trace
We are not sure what is causing it as there are no changes in the code. We checked and ensure that there is not change in our signing key and rollover signing key. We can see that the refresh token exist in the database (as indicated in the stack trace) and have not consumed.
Could you provide some guidance please?
Thanks a lot,
Minh Phan