Inconsistent HTTP Error codes across the authenticate and OAuth2 endpoints when downstream AM DS Repos are unavailable

The AM authenticate and OAuth2 endpoints respond with various different HTTP error codes if the Config, User or CTS stores become unavailable. See attached spreadsheet.

400 is particularly misleading - indicating a badly formed request from the client when in fact these are all server side errors (refresh to access token using the access_token endpoint and userinfo calls if the Userstore is unavailable). There are also 401s (unauthorised) and 404s (not found) - all indicate client side errors, when again it's at the server end where the problem lies.

The errors from any of these endpoints if any datastore becomes unavailable should be consistent - HTTP 503 perhaps or should server errors be hidden and a 403 returned?

Also not sure if some of the OAuth2 endpoints must respond with a particular 40x error irrelevant of the problem to be spec compliant.