Clarification on “No client identifier found” error during /connect/token request

[zomo01]

Hi Duende team,

Environment

• .NET Core version: 8.0
• Duende IdentityServer version: 7.0.6

Question

We occasionally see the following error in the logs when the /connect/token endpoint is called: "No client identifier found"

We understand that this typically occurs when the request does not include a client_id. However, we'd like to clarify the expected behavior in this case.

1. Is this situation considered normal under some circumstances (e.g., anonymous, expired session, malformed request)?
2. If yes, is there a specific reason this is logged as an error instead of a warning?
3. Are there any recommended best practices for handling or filtering such requests in production logs?

We are aiming to reduce unnecessary noise in our logs while still capturing actionable errors.

Thanks in advance for your support!

[RolandGuijt]

Looking at IdentityServer's code it seems that the mentioned error message not only occurs when there's no client_id but also when there are problems with it or the client secret like when they exceeds the maximum size.

How this should be logged is a matter of interpretation but we're thinking about making this more flexible. A colleague of mine is working on that and needs some feedback.

[zomo01]

Hi Duende team,

Thanks again for your earlier response and for sharing the details about potential causes of the "No client identifier found" error.

From what I understand, this message can occur in two cases

• actual misconfiguration (e.g., missing or oversized client_id or secret) which is an error that must be solved
• result of the normal flow when this is the expected behaviour and not (necessarily) a problem.

Could you please confirm if this understanding is correct?

We're trying to distinguish clearly between actionable misconfigurations and harmless noise, and your input would be very helpful.

Best regards.

[AndersAbel]

Sorry for the late response to this.

• actual misconfiguration (e.g., missing or oversized client_id or secret) which is an error that must be solved
  Yes, this can case the error to be logged.

• result of the normal flow when this is the expected behaviour and not (necessarily) a problem.
  No, it is not expected to happen during normal operations

• New suggestion: incorrect client configuration or someone actually trying invalid client ids. In any large scale deployment I would say that it is expected that external actors try to attack the installation. So while this is not the result of a normal flow, it is part of a normal deployment to see occasional errors of this kind logged.

[zomo01]

Thanks for the clarification.
Is there any way to identify where these invalid or misconfigured authentication requests are coming from — for example, the source IP address, the originating application, or the tool that is sending them? I'm trying to determine whether these are caused by a misconfigured internal client or potentially by external actors probing the system. Any guidance on how to trace or log this kind of information would be very helpful.
Best regards