"Unknown client or not enabled" error caused by old, no longer existing client #198
Unanswered
cliffi30
asked this question in
IdentityServer
Replies: 1 comment
-
I think the way you solved it is fine. The reason IdentityServer and the templates we provide don't include this behavior by default is that we are very careful with leaking information to potential attackers. User friendly solutions often also are attacker friendly. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
We have a lot of "Unknown client or not enabled" error messages in our LogServer. On investigation I found, that these are caused by authentication request from clients that do no longer exist in our identity server configuration. Practically it means, people still use old outdated bookmarks that where taken in the middle of a previous authentication process when the old client was still active. Users opened a client, got redirected to the identity server and for some reason created a bookmark right then.
I now created a method in our Login GET Method on the Identity Server that checks the returnUrl, which is send along when a client gets redirected to the idp. I simply parse the QueryString and then check the Client_ID. If it is a match for an old client, I redirect to a custom error page, telling the user about the outdated link.
This way the user will not end up on the default identityserver error page, not knowing what whent wrong and I have no longer the error messages filling up the log server and distracting us from other more serious issue.
However, this all looks a bit hand knitted and I am wondering if this is the best practice. I did have a look into the Duende documentation and first tried to implement the ICustomAuthorizeRequestValidator and to check the client_ID there but it seems that a class that implements ICustomAuthorizeRequestValidator is only called after the default RequestValidator. In our case, that will not pass of course.
What do you think would be the best approach?
Beta Was this translation helpful? Give feedback.
All reactions