I've updated the documentation with a section about errors. This behavior is defined more by the OAuth 2.0 spec than by me, so it's naturally a little out of sync with the rest of the API. Authentication is also just... weird when compared to pure data queries.

The answer is, it depends. In no case during implicit authentication is a 400 possible, sine you don't actually query the API in a way where we can provide a response code (you're just redirecting users). There is one place in explicit auth where a 400 is possible.

In short, during a redirect an error will be reported by either

1. Showing the user an error page.
2. Returning to redirect_uri with an error parameter.

Number 1 will occur if the error that was encountered makes it impossible to identify the application (or if the application has been flagged as malicious). Basically, if we can't safely redirect then we don't.

Number 2 occurs in the majority of cases, exactly what the error was will be indicated by the error parameter and optionally an error_description one as well.

During the explicit flow, it's possible for an error to occur when POST'ing to /oauth/access_token with the code generated via a user redirect. In this particular case, we do return a 400 and a JSON object like { error: { type: "some type", message: "some message" } }. The possible error types are the same as in the implicit flow (invalid_request, bad_parameter, and so on).

I've updated the documentation with a section about errors. This behavior is defined more by the OAuth 2.0 spec than by me, so it's naturally a little out of sync with the rest of the API. Authentication is also just... weird when compared to pure data queries.

The answer is, it depends. In no case during implicit authentication is a 400 possible, sine you don't actually query the API in a way where we can provide a response code (you're just redirecting users). There is one place in explicit auth where a 400 is possible.

In short, during a redirect an error will be reported by either

1. Showing the user an error page.
2. Returning to redirect_uri with an error parameter.

Number 1 will occur if the error that was encountered makes it impossible to identify the application (or if the application has been flagged as malicious). Basically, if we can't safely redirect then we don't.

Number 2 occurs in the majority of cases, exactly what the error was will be indicated by the error parameter and optionally an error_description one as well.

During the explicit flow, it's possible for an error to occur when POST'ing to /oauth/access_token with the code generated via a user redirect. In this particular case, we do return a 400 and a JSON object like { error: { type: "some type", message: "some message" } }. The possible error types are the same as in the implicit flow (invalid_request, bad_parameter, and so on).