Possible misalignment with spring-oauth2's check_token endpoint about spring-cloud-security

[dsyer]

That code comes from the UserInfoTokenServices which isn't used if you go to the /check_token endpoint instead. Is that what you were missing?

[DirkLachowski]

Maybe some missunderstanding on my side about the token flow. I have a bearer token and my resource server is trying to authenticate a user based on this token. If i manually present the token to my auth server's check_token endpoint i get a json hash as expected. I thought that the tokenInfoUri that spring-cloud security is using is this endpoint - but that seems to be wrong.

[dsyer]

It does use /check_token if you configure a URI for it. Otherwise it will try and use a "userInfoUri" and that's where the code you posted comes from. Docs here: http://projects.spring.io/spring-cloud/spring-cloud.html#_single_sign_on. If they aren't clear enough maybe we can pinpoint the problem here and make a change?

[DirkLachowski]

That are the docs i've used and that's the endpoint i've configured. At the moment i'm not sure if it's a problem with /check_token at all. I have two endpoint apps. One using a hand configured oauth setup (based on the sparklr/tonr samples) that works and one using spring-cloud security's resource server config. The later seems to have problems letting OPTIONS requests in. They are not send with a bearer token and work on the former app but not on the later, so the check_token code is not reached. I'll come back on this if i have deeper insight.

[dsyer]

None of the code in Spring Cloud is sending OPTIONS. I assume you have a browser client? Maybe if you could be a bit more precise about the actual problem you are having (as opposed to guessing the solution) we could get to the bottom of it.

[DirkLachowski]

My bad.

I have some ember.js based clients using torii on the ember side to authenticate against a spring-security-oauth based authentication server getting bearer tokens in response. My current setup on the resource server side (that is a different app detached from the auth server) is based on the sparkl sample and simply works.

We are now evaluating migration to microservices based on spring cloud. For that i have build a new auth server exposing a check_token endpoint so i can authorize requests to my edge services. The check token endpoint is accessible and if i curl it with a valid bearer token auth header and a matching token param i get my user info back.

In the current (working) setup, the browser sends an (unauthorized) OPTIONS request, gets a response and then sends a bearer authorized request.

My belief was that i could simply take my resource servers code, wrap it in an appropriate spring-cloud/spring-boot AppBootstrapper annotated with @EnableOAuth2Resource, add some config so the resource server verifies the token against the check_token endpoint and i'm done.

The problem is that i don't get that far. My browser client sends an unauthorized OPTIONS request and gets stuck. Obviously something is different between manually configuring oauth2-security and the @EnableOAuth2Resource way, but i have no clue what that could be.

[dsyer]

Spring (Cloud nor Security) will not handle OPTIONS requests for you so you must be doing that successfully in the server that works. It probably means you have a filter but in the wrong position in the chain or something?

[DirkLachowski]

Oh my god, i'm so stupid.

After placing the filter in the right position in the filter chain my requests are now reaching the resource server. Many thanks for that.

But...
Spring-cloud security is now sending a request to the check_token endpoint, but there still seems to be a point i'm missing. As far as i can see, the sended request contains a valid auth header with a bearer token and the configured uri, but the default check_token endpoint expects a token parameter additional to the token header. How do i configure the check_token url in the resource server so that the parameter gets send?

[DirkLachowski]

For now, i've dropped @EnableOAuth2Resource and reverted to manually configuring oauth2 using our cassandra based token store. Maybe the preferable solution regarding performance.

But i'm still curious how to use the check_token endpoint with cloud-security...

[ychen00]

@DirkLachowski Did you find out a way to get around the required token parameter when check_token end point is used? It's still the case in spring boot 1.3.2.RELEASE. Isn't the value the same as the token in the header?

[dsyer]

Generally speaking a check_token endpoint requires basic auth as a client (not token authentication) and you always have to send it a token as a parameter (in the request body). If it is configured correctly your client app should have a RemoteTokenServices which will require a client id and secret to operate correctly. N.B. the autoconfiguration for this feature has moved to Spring Boot, so if you have a crisp description of an actual issue (preferably with a sample app), please post again there.

[ychen00]

Thanks for the clarification, Dave! After configuring the remote token services, I'm able to use the check_token end point from the resource server now. I tried to use the same end point as the userInfoUri in an OAuth2 client with OAuth2 SSO enabled, see the sample app at https://github.com/ychen00/oauth2-client, I got bad request 400 because it's looking for the token parameter. Is it a good practice to use the end point in the client for this purpose? It seems natural to me although one can implement another rest end point to do the same thing. What I did after this was to override the default userInfoTokenServices in the client with the following code:

@bean
public ResourceServerTokenServices userInfoTokenServices() {
RemoteTokenServices tokenServices = new RemoteTokenServices();
tokenServices.setClientId(clientId);
tokenServices.setClientSecret(clientSecret);
tokenServices.setCheckTokenEndpointUrl(userInfoUri);
return tokenServices;
}

and it worked.