Spring-security-oauth: Ability to have immortal refresh tokens

[collinpeters]

Currently the refresh token support in DefaultTokenServices is built as an int and must have a value which is either the default in the class (30 days), or injected globally. Then it can be overridden per OAuth client. What I don't see is a way to set them to live forever. This would be useful for trusted clients.

[collinpeters]

Hmm... I don't see an easy way to override this behaviour.

1. My first thought was to override getRefreshTokenValiditySeconds, however clientDetailsService is private (I suppose I can inject into my sub-class as well)
2. My second though was to override createRefreshToken, but that is private
3. Also it seems that DefaultExpiringOAuth2RefreshToken is hard-coded

Is there any clean option here other than just making an extremely high expiration like the year 5000?

[collinpeters]

Also, the default SQL schema uses an int whereas the code is a long... so the maximum date you could use is somewhere in 2038

[dsyer]

I suppose I'm open to allowing this as an option but I would caution against using it in practice (do you trust all your clients and all the people who use them or administrate them forever?).

[collinpeters]

Yeah, I understand that element of it. I'm wondering how most websites do it then... for example if I integrate Bitly and Twitter, once I allow access it does not seem to prompt me again. I guess I'm not 100% sure about that example but I'm sure you get my drift

[dsyer]

Not sure about Bitly. Last time I looked Twitter was OAuth 1.0 so there are no refresh tokens. I'm not even sure Facebook or Google issue refresh tokens, so it's moot (do they?).

[vincenzovitale]

+1
In personal devices (user agents) with high trust from the user and normally already protected, we never want to re-prompt the user for the password. And having an evergreen refresh token stored in the backend (client) is important.
Regarding Google, in their playground application:

https://developers.google.com/oauthplayground/

it is written that refresh tokens never expires.

It is true that the specs so not dictate to have infinite refresh token but the subject must have been considered if they added the note:

The authorization server MAY issue a new refresh token, in which case the client MUST 
discard the old refresh token and replace it with the new refresh token

[dsyer]

That part of the spec is sort of relevant, but it doesn't imply to me that refresh tokens would be immortal, just that you can get a new one without re-authenticating. It is also already supported by Spring OAuth: the DefaultTokenServices supports issuing a new refresh token if its reuseRefreshToken is "false".

[totof3110]

From personal experience Google's refresh tokens don't seem to expire at all. I've used the same refresh token for several months now and it still works. Granted it could suddenly expire tomorrow but that's unlikely.

A security issue is that Spring OAuth2's JWT refresh tokens are not stored on the server by default, so there is no practical way of revoking them. A user can go to a page on Google and see the list of apps that have active refresh tokens and individually revoke them. I think Facebook has a similar feature.

IMO, having non-expiring refresh tokens is pretty useful when you connect different internal services together: the user gives an refresh token to a batch server who then invokes APIs on the resource server to do some kind of sync (slightly contrived example). It would be cumbersome if that sync stopped every couple weeks and the user had to manually go an generate a new refresh token to restore it.

[shlomicthailand]

Hi
i absolutely agree with totof3110 - this is exactly our case , a server that sync with our service after the user has put his refresh token in there.
please consider this feature - its a must.

[jricher]

We've implemented optionally immortal refresh tokens in our own service, MITREid Connect. To do this with SECOAUTH, we have our own implementation of token services and token classes that give us the flexibility we need to make it work.

[shlomicthailand]

jricher - thats impressing , and i'm sure the feature list that differ from original spring is long, but i would try to contribute this instead of making my own fork. if this is one class or 2 then its ok and one can wait for a version upgrade but from my experience when you do more , after 2 spring versions it would not be easy to upgrade.

[jricher]

We haven't officially forked the Spring component, but we're overriding the majority of its functionality at this point. We'd welcome your input over on our own project, but note that it's an implementation more than it is a general-purpose library. I doubt you'd be able to get this one piece of functionality by pulling just a couple of classes.

[shlomicthailand]

Dave i think there is a problem with the refresh token grant. looks like it would not be recreated while getting new access token , which mean the client cannot use it forever.
I looked closely in the code code in DefaultTokenServices and looks like in the createAccessToekn method there are remarks and also code that indicate if the refresh token expired a new one is created. but this code is not called when user refresh an access token (only the first time the access token is requested in authorization_code grant for example)
when user call refresh token - the code in refreshAccessToken method check the refresh token expiration and throws exception if it does. this somehow contradict the policy of the previous method to recreate refresh token.
hope you managed to understand me :-)

[gerar2]

It seems that creating immortal refresh tokens is not working when using JWT.
I have a client configured with refreshTokenValiditySeconds(0) but when using JwtAccessTokenConverter the token expire at the same time as the access token.

Could it be a bug or am I missing something?

Thanks

[dsyer]

This issue is closed. If you have a new issue, please open a new ticket.