Re: [abacus] Securing REST endpoints using OAuth bearer access token


Saravanakumar A. Srinivasan
 

> 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.

>> 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.

Agree with you about the comments on *before* and about not polluting the code with support for URI query and Form-Encoded parameters.

>> 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).

+1, will update the implementation to return 400 when we get authorization parameters with or without Authorization header.

> or is otherwise malformed

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

How would we define a malformed Authorization header? Would a header value not starting with 'bearer ' become a malformed token? 
and how about a header value of 'bearer plaintesttoken'  -  would we consider that as malformed or just an invalid_token? 

How about we just depending on JWT verification to classify these errors using its error message +  401 HTTP response code? is that good enough?

Thanks,
Saravanakumar Srinivasan (Assk),


-----Jean-Sebastien Delfino <jsdelfino@...> wrote: -----
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
From: Jean-Sebastien Delfino <jsdelfino@...>
Date: 09/30/2015 05:16PM
Subject: [cf-dev] 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_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@...> 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? 



Thanks,
Saravanakumar Srinivasan (Assk),

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



Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.