Date
1 - 9 of 9
[abacus] Securing REST endpoints using OAuth bearer access token
|
Saravanakumar A. Srinivasan
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 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) |
|
|
|
Sree Tummidi
Hi,
The access token that you are passing in the header serves as both a proof of authentication & authorization(scopes allowed) The validation of the request includes checking for the presence of the bearer token and then further checking for the validity of the bearer token. UAA also exposes an endpoint called check_token but its not a recommended path as this increases the traffic to the server. The barer token generated by UAA is a self validating JWT token which can be to checked for the issuer, signature, expiry, scope etc. Thanks, Sree Tummidi Sr. Product Manager Identity - Pivotal Cloud Foundry 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) |
|
|
|
Jean-Sebastien Delfino
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 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) |
|
|
|
Jean-Sebastien Delfino
+1 to that, that's what we're implementing, i.e. not bombarding UAA with
toggle quoted message
Show quoted text
token validation call traffic each time we get usage posted to Abacus :) Thanks! -- Jean-Sebastien Sent from my DynaTAC 8000x On Wed, Sep 30, 2015 at 4:45 PM, Sree Tummidi <stummidi(a)pivotal.io> wrote:
Hi, |
|
|
|
Filip Hanik
I wouldn't recommend writing this library by hand when there are plenty of
libraries to pick from. Take a look at "Client libraries" at http://oauth.net/2/ and there are plenty more. On Wed, Sep 30, 2015 at 3:58 PM, Saravanakumar A Srinivasan < sasrin(a)us.ibm.com> wrote: I am working on implementing (see Github commit at [1] for more details) |
|
|
|
Jean-Sebastien Delfino
Exactly. We're already using the jsonwebtoken [1] library for the handling
toggle quoted message
Show quoted text
of JWT tokens. The work we've been discussing here is more about integrating that token validation and the authorization logic in the rest of our code, and in particular where do we hook the token validation, before or after our incoming request validation code? For a more comprehensive authentication solution (which we've not really started to work on), I'd suggest to look at a library like Passport [2] for example which works well with the Express framework we're using and comes with all kind of authentication strategy plugins, incl. support for JWT with these plugins [3] for example. [1] https://www.npmjs.com/package/jsonwebtoken [2] https://www.npmjs.com/package/passport [3] https://www.npmjs.com/search?q=passport+jwt - Jean-Sebastien On Wed, Sep 30, 2015 at 5:30 PM, Filip Hanik <fhanik(a)pivotal.io> wrote:
I wouldn't recommend writing this library by hand when there are plenty of |
|
|
|
Saravanakumar A. Srinivasan
> The bearer token generated by UAA is a self validating JWT token which can be to checked for the issuer, signature, expiry, scope etc. To validate JWT, we are using HMAC Algorithm and a secret, would we be able to use PEM encoded public key for RSA? Looks like this depends on how we have configured the UAA(with symmetric or asymmetric token signing keys). Is my understanding correct? Thanks, Saravanakumar Srinivasan (Assk), -----Sree Tummidi <stummidi@...> wrote: ----- To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...> From: Sree Tummidi <stummidi@...> Date: 09/30/2015 04:46PM Subject: [cf-dev] Re: [abacus] Securing REST endpoints using OAuth bearer access token Hi, The access token that you are passing in the header serves as both a proof of authentication & authorization(scopes allowed) The validation of the request includes checking for the presence of the bearer token and then further checking for the validity of the bearer token. UAA also exposes an endpoint called check_token but its not a recommended path as this increases the traffic to the server. The barer token generated by UAA is a self validating JWT token which can be to checked for the issuer, signature, expiry, scope etc. Thanks, Sree TummidiSr. Product Manager Identity - Pivotal Cloud Foundry On Wed, Sep 30, 2015 at 2:58 PM, Saravanakumar A Srinivasan <sasrin@...> wrote:
|
|
|
|
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:
|
|
|
|
Sree Tummidi
Yes, UAA supports both Symmetric & Asymmetric patterns for token signature
and verification. My recommendation would be to go for the Asymmetric pattern as this is a standard where signatures are concerned. -Sree On Wed, Sep 30, 2015 at 10:46 PM, Saravanakumar A Srinivasan < sasrin(a)us.ibm.com> wrote: The bearer token generated by UAA is a self validating JWT token whichcan be to checked for the issuer, signature, expiry, scope etc. |
|
|