Better way to differentiate between 400 errors.

[markhildreth-gravity]

When using GetProfileAndToken, there are a few cases where we might have an error. Namely:

• The Client ID was invalid.
• The Secret key was invalid or expired.
• The code itself was invalid.

We want to handle these cases differently (e.g., have our callback handler return a 500 in the first two cases so alarm bells go off, but a 400 in the latter case since not our problem). However, it's difficult to do this because of the way that the error is returned in the SDK. The JSON bodies of these responses looks like this:

{"error":"invalid_client","error_description":"Invalid client_id."}
{"error":"invalid_client","error_description":"Invalid client secret."}
{"error":"invalid_grant","error_description":"The code 'XXXYYYZZZ' has expired or is invalid."}

...but the workos_error.HTTPError only returns the following:

Code: 400
Status: 400 Bad Request
RequestID: A UUID
ErrorCode: ""
Errors: []
FieldErrors: []
IsRequestError: true
Message (see below)

The message ends up using this logic to mash up the strings, so the three errors I talked about above would result in these Message values:

"invalid_client Invalid client_id"
"invalid_client Invalid client secret."
"invalid_grant The code 'XXXYYYZZZ' has expired or is invalid."

So in the end, while in theory the SDK gives us an error code so that a developer doesn't need to parse a string, I still end up needing to parse a string.

Ideally, the code (e.g., "invalid_client" and "invalid_grant") would be in a field like "ErrorCode.

[emaincourt]

That is still very relevant as it also applies to handling all the authentication errors which is basically impossible in the current state of the SDK if I'm correct. Why was #203 closed ?