Announcement Announcement Module
Collapse
No announcement yet.
Token validation from separate resource server Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Token validation from separate resource server

    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.

  • #2
    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


    • #3
      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.

      Comment


      • #4
        Originally posted by pulapura View Post
        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.

        Comment


        • #5
          Thanks for your quick responses!! I appreciate it.

          - Sudip.

          Comment

          Working...
          X