Token validation from separate resource server

[pulapura]

Hi

I am trying to separate out the authorization server and resource server based of the sparklr/tonr example. From the docs, it does not look like there is a standard way of interaction between a remote resource server and an authorization server. I was hoping to find some implementation like say a "RemoteTokenServices" that would call into /oauth/validate on the authorization server passing in an access token for validation. So, my question is am I correct in assuming that there is no such implementation available today in Spring OAuth and I would have to write a custom TokenServices on the resource server to validate the token against a remote authorization server.

Thanks
Sudip.

[Dave Syer]

I think most people doing this are using JdbcTokenStore (or a custom TokenStore) shared between the 2 servers. A remote token service would be quite practical I think, but you need another endpoint which isn't part of the spec, so we haven't added it to Spring Security OAuth as yet. If you want a remote token service you could check out this (and the associated endpoint on the auth server): https://github.com/cloudfoundry/uaa/...nServices.java.

[pulapura]

Thanks Dave. I took a look at the class you provided. I had a couple of questions about the class. Some are fairly obvious, but just want to confirm:
1) The other endpoint you talk about is the token validation endpoint on the authorization server, in the class referred to as checkTokenEndpointUrl?
2) I see that you pass in the clientId and clientSecret as the Authorization for the resource server. So, every resource server also is responsible for obtaining a clientId and clientSecret from the authorization server? From the authorization server, it is as good as a request coming in from a client(in OAuth terms)?
3) On a general note, do you see any reason why validation of the token isn't outlined as a specific step in the OAuth spec? It would have been nice to follow a standard protocol for that too.

Thanks
Sudip.

[Dave Syer]

1) The other endpoint you talk about is the token validation endpoint on the authorization server, in the class referred to as checkTokenEndpointUrl?

Yes. It's a non-standard endpoint.

2) I see that you pass in the clientId and clientSecret as the Authorization for the resource server. So, every resource server also is responsible for obtaining a clientId and clientSecret from the authorization server? From the authorization server, it is as good as a request coming in from a client(in OAuth terms)?

That's the way we do it - use the client details service to register secrets fort resource servers. You could do any type of authentication you feel comfortable with.

3) On a general note, do you see any reason why validation of the token isn't outlined as a specific step in the OAuth spec? It would have been nice to follow a standard protocol for that too.

I guess because the token can contain pretty much arbitrary information that could be useful to a resource server (e.g. in Spring Security terms, the user's authorities). It's really up to the auth server and resource servers to agree on what information to exchange, so it's probably a good thing that the spec doesn't make anything mandatory.

[pulapura]

Thanks for your quick responses!! I appreciate it.

- Sudip.