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