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 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(a)pivotal.io> wrote: -----
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
From: Sree Tummidi <stummidi(a)pivotal.io>
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 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)