[Feature Request] Offer specific Exceptions instead of generic MsalServiceException

Is your feature request related to a problem? Please describe. Currently there are only two exception types. MsalClientException, MsalServiceException.

All further information, which exact error case is present, are embedded in long magic strings.

This makes the coding very complex and error-prone. Furthermore, it actually contradicts the .NET design recommendation that specific exceptions and no generic exceptions should be thrown. https://docs.microsoft.com/en-us/dotnet/standard/exceptions/ https://docs.microsoft.com/en-us/dotnet/standard/exceptions/how-to-use-specific-exceptions-in-a-catch-block

In addition, it is very time-consuming to analyze errors in log systems, e.g. Application Insights, on the basis of their texts/exception messages and not on the basis of their types.

Describe the solution you’d like Please provide specific exceptions.

Example: when client credentials expire (its secrets), you just get a MsalServiceException with a very long text.

Just provide a e.g. MsalClientCredentialsExpiredException (Can inherit from MsalServiceException to stay compatible with existing code) with additional properties (which client id). This makes programming more secure and we don’t need magic strings anymore.

[BenjaminAbt]

are not guaranteed to be stable by AAD.

This is the problem that makes so much existing code buggy - and often this is critical code because it’s all about identity. At the end of the day, it’s Microsoft that can plan the behavior. We as consumers of this library don’t notice until it goes bang. This is depressing - and does not create trust.

Microsoft has to orchestrate that. No one else can do that. Other identity providers get this right, too. This is an identity system. We as developers and customers must be able to trust AAD. The experience has to be better.

With other things, the community can fix such deficits itself, because the errors are stable (e.g. https://github.com/Giorgi/EntityFramework.Exceptions which solves the generic exception behavior of EFCore). But in this case, Microsoft has to fix it.

[bgavrilMS]

Got it, the technical solution is not that complicated. The problem here is that the suberrors (https://docs.microsoft.com/en-us/azure/active-directory/develop/reference-aadsts-error-codes#aadsts-error-codes) are not guaranteed to be stable by AAD.

We can provide typed exceptions for the 8 big error codes (invalid_request, invalid_grant etc.). we already provide MsalUiRequiredException for 2 of them.

CC @jmprieur