3

CloudFoundry's UAA has a RemoteTokenServices class (part of Spring oauth2 too) that does the authorization token validation by going to the UAA server's check_token endpoint. UAA has sample api and app applications that serve as a resource server and a client application respectively.

From the sample api's spring-servlet.xml:

<bean id="tokenServices" class="org.cloudfoundry.identity.uaa.oauth.RemoteTokenServices">
    <property name="checkTokenEndpointUrl" value="${checkTokenEndpointUrl}" />
    <property name="clientId" value="app" />
    <property name="clientSecret" value="appclientsecret" />
</bean>

Do you know why this class (and the check_token endpoint that needs these values encoded in an Authorization header) needs a clientId and a clientSecret? It seems to me that it puts dependency on the client application from the resource server. How can I use multiple client applications if one of the client secrets is "hardcoded" here?

Márton Sereg
  • 283
  • 2
  • 9

1 Answers1

1

I've figured it out myself by reading the UAA documentation thoroughly, and I still think that it's confusing in the UAA sample applications:

  • The clientId and clientSecret values should be the client id/secret of the api application (api/apiclientsecret) in the sample as the resource server should authenticate itself to the UAA server with basic auth when calling the check_token endpoint so the UAA can be sure that the request was made by a valid, registered resource server.
  • To be able to do that, the resource server must also be registered as a client in UAA with client_credentials as authorized-grant-type.
  • The token that should be checked is sent in the POST request body.
Márton Sereg
  • 283
  • 2
  • 9