Feature request: SDK Exception Handling

[DevEnable]

Prerequisites

• I have searched the repository’s issues, Kinde community and public roadmap to ensure my feature request isn’t a duplicate
• I have read the contributing guidelines
• I agree to the terms within the code of conduct

What is the problem you’re trying to solve?

I think the current approach that Kinde has towards exception management in that SDK could do with some improvement. Here's Kinde's code when authentication fails.

if (!response.IsSuccessStatusCode || string.IsNullOrEmpty(content))
            {
                throw new ApplicationException("Invalid response from server: No token received");
            }

There's two issues with this:

• There is no way for a developer to understand why authentication failed unless they attach a debugger before the ApplicationException is thrown as the actual error is never reported, just a generic "no token received" error message. This is going to be problematic when troubleshooting issues outside of a developers local machine (e.g. production). If data sensitivity is a concern at least allow for a config value to allow for sensitive exceptions to be thrown (just like with the .NET OIDC libraries you can have a config setting to allow for PII data to be output)
• Kinde is throwing ApplicationException. Both Microsoft and Jetbrains state in their base practices and code analytics do not throw ApplicationException (official docs). The problem with throwing just the base Exception and ApplicationException types is that they are so general they give very little indication with what went wrong. I would suggest throwing a custom Kinde exception or using one of the .NET security or HTTP exception types.

For my purposes I'm mainly concerned with issue 1. I can live with the ApplicationException issue but I suspect it might cause downstream issues for Kinde, particularly with enterprise .NET customers as they tend to have more stringent standards reinforced by static code analysis.

What solution would you like to see?

As per the problem.

• Kinde to allow for actual error messages to be thrown up to calling code so it can be logged for troubleshooting, particularly in environments where you cannot attach a debugger. Right now, I would call Kinde's Management Library unsupportable in the sense there is no way to know when authentication failed what the issue might be in a production environment. For me to use this library with any comfort I would need to fork the repository and create my own build, somewhat defeating the purpose of using an external provider in the first place. I would imagine I'm not the only customer who's going to have this issue.
• Review the use of ApplicationException and consider more appropriate exception types.

Additional information

No response

[DevEnable]

As an example, over the last couple of days I have been troubleshooting an issue as to why I couldn't authenticate. I was able to replicate the issue with Postman (which I needed to fall back on as there was no easy way to do it), and then eventually I dug up the repository to look at the code and was able also replicate the same issue in .NET.

The only way to actually troubleshoot right now is via a debugger. Which doesn't leave a lot of confidence in supporting a Kinde solution in production.

[coel]

Hi @DevEnable , thank you for your feedback, this is definitely something we will consider for a future release.

You may find OpenTelemetry (or an out of the box solution like DataDog APM) useful for tracing requests in production.

[DevEnable]

Hi @coel. I can use those solutions (currently using Application Insights through an Open Telemetry Provider), but unfortunately the quality of data that those tools present is only as good as the quality of the data coming in. As the exception thrown by Kinde does not include pertinent details, nor does it log the actual error through any logger existing in the application context (e.g. by resolving to an ILogger) that data would not be present for a customer.

I would imagine that Kinde has logging available on its backend systems, so can uncover the issue but customers would need to go through your support team to get access resulting in both a longer resolution time (impacting SLAs) as well as increased customer support costs.