This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Token validation from separate resource server

Sep 6th, 2012, 01:29 AM

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.

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.

Comment

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.

Comment

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.