What HTTP code should I use when I can’t authenticate to third-party services with login and password provided by the client earlier?

Question

I am implementing a service from a website that does the following:

• My website (A) connects to some external services provided by third parties (B, C and D) using webservices.

• In fact A is a REST API in the backend that is accessed by frontend javascript. The frontend is not necessarily mine, the client can develop his own frontend by accessing my REST API if so he prefer.

• Each user of my site A has a login and password on site B, one on site C and one on site D. Each of these logins and passwords of sites B, C and D are saved in my database, through a functionality offered to the user for this purpose. These logins and passwords are different from each other and different from the login and password that I use to log the customer into the site A.

• There are some features that the customer accesses on my site A that depend on the integration with services B, C and D, and at this time the login and password of the respective integrated service is used.

• Sometimes the login and password sent to B, C or D are wrong because my user (from site A) saved them incorrectly when using the functionality that saves these logins and passwords in the database.

Well, my question is what HTTP status code I return to the client’s browser when the login and password for the integration are wrong.

• 400 - Bad Request does not seem good because it is for malformed HTTP requests and the request received by my site A is well formed.

• 401 - Unauthorized doesn’t sound good because that would be for an authentication or authorization failure on the A site which is where the browser is connecting. It turns out that the authentication failure was in the integration with site B, C or D and not site A. In addition, in case of this code be applied, a header WWW-Authenticate should be present to allow the browser to (re)authenticate on my site, which makes no sense in my case.

• 403 - Forbidden also does not seem correct because the client has yes access to requested functionality, the problem is only that it has not been configured properly.

• 404 - Page Not Found also not correct because the actual page exists and the customer should know this.

• 405 - Method Not Allowed also not correct because the HTTP method used (GET, POST, PUT, etc) is correct.

• 406 - Not Acceptable and 506 - Variant Also Negotiates also do not seem to be correct because it has to do with the negotiation content that has no relation to the problem occurred.

• 407 - Proxy Authentication Required also does not seem to be correct because it tells the client to authenticate in a proxy before trying the request again with site A. It occurs that the request with site A is valid and does not need any proxy, the problem is between A and B, C or D.

• 409 - Conflict also does not seem to be correct because this is in case of a conflict between two or more requests that change the server state.

• 412 - Precondition Failed and 417 Expectation Failed also does not seem to be correct because it has to do with the contents of the header of the request, which in my case have no problem.

• 421 - Misdirected Request also does not seem to be correct because this occurs when the server is not able to produce a client response, and this is not the case.

• 422 - Unprocessable Entity also does not seem to be correct because this is in case the request has some semantic error. Turns out the requisition is correct after all.

• 424 - Failed Dependency is used by Webdav in the PROPPATCH method to specify that changing a property failed because it triggered the change of another property and this other property failed, as in RFC4918. I think using this to represent a login and password error would be inappropriate.

• 500 - Internal Server Error is for when an unforeseen and untreated error occurs on the server, or for generic server-side errors. This is not the case.

• 502 - Bad Gateway also does not seem to be correct because this is to signal an invalid response from the integrated service B, C or D. It occurs that the response from B, C or D is valid, although it is an error response. It would make sense if the login and password were something private site A with one of these other sites, but in case I’m using a login and password given by the customer.

• 503 - Unavailable Service also does not seem to be correct because this is for when the server is congested or under maintenance, which is not the case.

• 510 - Not Extended does not seem to be correct because after reading the RFC2774, This has to do with extensions specified in the request headers. In my case there is no header with any relevant special property.

• 511 - Network Authentication Required also does not seem to be correct because this is for when a problem occurs with the client-side network infrastructure to get access to the site A. In my case, if the request came to site A, it is because it already has the access.

• As for the codes 402 - Payment Required, 408 - Request Timeout, 410 - Gone, 411 - Length Required, 413 - Payload Too Large, 414 - Request-URI Too Long, 415 - Unsupported Media Type, 416 - Request Range Not Satisfiable, 418 - I’m a Teapot, 423 - Locked, 426 - Upgrade Required, 429 - Too Many Requests, 431 - Request Header Fields Too Large, 451 - Unavailable For Legal Reasons, 501 - Not Implemented, 504 - Gateway Timeout, 505 - HTTP Version Not Supported, 507 - Insufficient Storage and 508 - Loop Detected, these clearly have no relation to my problem.

There are some unofficial status used around, but none of them seem to suit either.

So none of the 4xx and 5xx official HTTP codes I found specified anywhere seem to make sense to my case. So, what should I do? What HTTP code should I use and why? If none of the official status codes are adequate, would it be better for me to invent one for that or force the use of some already existing ones? If you are forcing the use of an existing one, what it would be and why?

Furthermore, I note that this problem of mine must be something common and recurrent, and therefore should already be covered in some of the existing codes.

Another point is that I am not sure if it is a problem in the client (4xx) or server (5xx), since the client request could not be answered due to a problem in the integration in the server side (5xx)however the reason for this failure is because the client provided incorrect information (4xx), but this information was not passed by the client at the time of the request, but was stored on the server side (5xx).

Note 1: I am aware of the questions about storing customers' login and password for third-party services rather than asking them for each request and the security implications of this. However, what I’m asking has little bearing on this.

Note 2: Considering the comments and the two responses posted, I clarify that I cannot simply return 200 indiscriminately for any request to then impose on the client to interpret the answer to know if there was an error or not. Return a 400 for any and every error and expect the same from the customer is also out of the question. It is an important requirement that HTTP status code should be an informational code.

Note 3: For now, I am using a custom code 432 for this situation.

Answer 1

As you do multiple operations, some work and others don’t, you can use the multi status (207) and list the appropriate status by operation.

Answer 2

I consider that 403 (Forbidden) makes sense in this case. I’ve already used 400 (Bad request) in similar cases - it’s a little accurate, but I still think acceptable.

The justification for the use of track 4xx is that it is a client error, although detected on the server. It was the customer (the user, not the software he is using) who reported incorrect credentials.

Answer 3

A user had posted an answer, but he deleted it. Personally, I don’t agree with her because I don’t think it’s right to return 200 in case of error, but anyway, I copy the deleted answer from him here the way it was when it was deleted so that the content is not lost:

After reading about it:

• http://blog.thefrontiergroup.com.au/2012/08/http-status-codes-and-restful-api-crafting

• http://docs.microsoft.com/en-us/rest/api/storageservices/fileservices/common-rest-api-error-codes

• http://racksburg.com/choosing-an-http-status-code/

I would stay with the answer found in the last:

There’s a Lot of smart people at Facebook and they built an API that only Ever Returns 200.

The basic argument Against bothering with specific status codes is this: the existing status codes are Much Too general for a Modern website/API

Translation: Status codes are too vague for modern applications.

Microsoft presents 25 possible situations for Code 400.

Answer 4

I would go from 500. Explain.

Think who’s integrating with your "A" API doesn’t care - from what I understand your question - about authentication for these internal Apis. The fact is that the user of your API tried to make a request and could not complete it.

As a 401 is most expected for the current request and all 4xx are Client Errors, i would treat this problem as an unforeseen error on the server. That is, a 500 error. As it is in the sent link:

The server encountered an Unexpected condition that prevented it from fulfilling the request.

It seems to be an unexpected condition. There is nothing the user can do in the "A" Rest service and support (or development team) will need to act to resolve the situation. To help, add an error return message (or error code) with the explanation: authentication to an internal system was not possible to be completed by a user problem or password for the B/C/D API (if you can provide these details, of course).

Even if you don’t agree with my answer, keep in mind that you won’t always find the right HTTP code for your problem. An example: what HTTP code to use to validate if a field of a register is larger than allowed? You’ll find there’s a good discussion on the Internet about this.

Ideally, choose the HTTP code that makes the most sense to you and set it as the default for the problem you’re solving.

Answer 5

It doesn’t really seem to have a code that meets this situation, since in your case the request will be processed correctly.

I believe code 200 is the most appropriate, with a custom error message.