Re: [abacus] Securing REST endpoints using OAuth bearer access token
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_requestAIUI 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 malformedOther malformations of that Authorization header would translate to a 400
On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <
I am working on implementing (see Github commit at  for more details)