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