Can / should I refresh an OAuth2 token with every request in spring security

Question

We use the username-password grant to connect our JS client to our REST server. In a way the token returned by oauth/token is our session, as it allows access to the backend for a limited time.

We would like to refresh that session/token every time we make a request to the backend using the token.

I know there is this refresh token issued by the server and I could use it to refresh my token after it has expired.

The thing is: I don't want to make it the client responsiblity to catch token expired exception and re-authenticate or schedule a refresh prior to token expiration. I want the token to refresh itself until it is not used any more for a limited amount of time - just like a session. (I also wouldn't like it to issue a refresh request with every "data" request, though I think I remember reading, a refresh token is only valid once..?!)

Is there a way to do that in spring security or will I have to build some custom implementation of the token store or whatever part I choose?

Since I can't really find an answer (hence the post) I'm thinking: Maybe it is not wise to do this, though I can't think why. If I can steal the token, I can steal the refresh token as well. So I guess I don't really see the point in having a refresh token in the first place..

EDIT

In response to Luke Taylor's answer I'll clearify our use case.

• We have a REST server that holds application data like persons. but also provides access to our content management and allows clients to post to facebook. It encapsulates application logic and data storage
• We have a fully fledged client application already in place that has its own security layer and justs accesses the data on our REST server via client credentials flow. Who can do what is decided on the client side
• We have several medium and small applications like a contact app on facebook that access the data on the REST server also using client credentials
• We are now developing a client application using only javascript that will access the REST layer to do all the stuff the big client application does but also needs to provide a means to authenticate individual users and allow multi tenancy. Therefore this new client application uses the username-password grant to authenticate and method level security to authorize the users

So we have a REST server that needs to provide complete access to our trusted application that does its own security stuff and that same server needs to provide access for users of our new multi tenancy javascript client application. In production we will have several REST servers each with its own database but the core will always be the same, so in theory one server should be able to handle all.

Answer 1

I want the token to refresh itself until it is not used any more for a limited amount of time - just like a session

This doesn't really make sense (in an OAuth2 context). The access token is issued by the authorization server, which decides how long it is valid for. It is "used" at a resource server, which may be completely separate from the authorization server, so there is no facility in OAuth2 to connect usage with the lifetime of the token. It would in theory be possible to hack something together which made this work, but it sounds like a bad idea.

If I can steal the token, I can steal the refresh token as well. So I guess I don't really see the point in having a refresh token in the first place..

The access token is used repeatedly and sent by the client to servers other than the authorization server. The refresh token is retained by the client and only sent back to the authorization server. A client also has to authenticate to successfully use a refresh token, so the client id and secret would also have to be compromised.

It's not really clear from your question why you are using OAuth2. You should probably expand your question to clarify this. If there is only one client and a REST server, why not just use something like BASIC auth over HTTPS?

Also, is the client a browser-based app? If so, the username/password grant isn't really suitable for use in an untrusted client.