I've updated the [documentation][1] with a section about errors.  This behavior is defined more by the [OAuth 2.0 spec][2] 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).


  [1]: http://dev.api.stackexchange.com/docs/authentication
  [2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-22