Unless I missed something in my reading of section 3-1 of RFC 6350, I don't
see where it suggests that we'd need to validate all required parameters of
the request *before* authenticating. The spec describes status code 400
before 401 and 403, but could that be just because 400 < 401 < 403? I'm not
sure that necessarily translates to a sequencing of the checks associated
with each status code.

Here's my interpretation of the section about the 400 status code -- which
could very well be wrong, it's just my interpretation :)

invalid_request
The request is missing a required parameter,

AIUI RFC 6350 doesn't mandate any parameter, so I'm not sure why this is
even mentioned here. The spec actually discourages the use of (URI query
and Form-Encoded) parameters for authorization so I'd advocate for not
polluting the code with support for these parameters in the first place.
I'm also not reading that sentence as requiring the validation of other
application specific parameters (well outside the scope of RFC 6350) to be
performed *before* the authentication check.

includes an unsupported parameter or parameter value,

Makes sense to me, we could reject these OAuth authorization parameters
with a 400.

repeats the same parameter,

Same here, reject one or more, basically any, authorization parameters.

uses more than one method for including an access token,

The above logic would apply here too, we'd only support the Authorization
header (and just one).

or is otherwise malformed

Other malformations of that Authorization header would translate to a 400
as well.

Thoughts?

-- Jean-Sebastien

On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <
sasrin(a)us.ibm.com> wrote:

I am working on implementing (see Github commit at [1] for more details)
an Express middleware to authenticate incoming requests using OAuth bearer
access token. We want to make sure our implementation follows the OAuth 2.0
Authorization Framework specification[2] when processing client requests.

While reading the specification I came across a section[3] where the spec
lists error codes to use when we get an invalid request. In there, the
invalid_request error code seems to suggest that we need to validate
required request parameters for a particular request before we authenticate
the user and return HTTP response code 400 with appropriate error code and
error message. It also mentions that we need to return HTTP response code
401, when a request does not contain any authentication information. So it
sounds odd for me to validate the request parameters before we validate the
authentication of the request.

Any thoughts?


[1]
https://github.com/cloudfoundry-incubator/cf-abacus/commit/cbadf4f287dd6930321b6332a54f388fb51e2524
[2] http://tools.ietf.org/html/rfc6750
[2] http://tools.ietf.org/html/rfc6750#section-3.1

Thanks,
Saravanakumar Srinivasan (Assk),

Bay Area Lab, 1001, E Hillsdale Blvd, Ste 400, Foster City, CA - 94404.
E-mail: sasrin(a)us.ibm.com
Phone: 650 645 8251 (T/L 367-8251)