Enhancement: specify lifespan for refresh_token

[fredbi]

Do you want to request a feature or report a bug?
feature

What is the current behavior?
refresh token never expires

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
N/A

What is the expected behavior?
have an environment setting to limit life span of refresh tokens

Note that this behavior is not defined by RFC 6749, or OIDC extensions. It is up to implementations to decide whether they chose to allow such expiry to occur or not.

Which version of the software is affected?
beta-9

[aeneasr]

This has been removed intentionally as refresh tokens are long living credentials and do not have an expiry time defined. To revoke refresh tokens you can use the /oauth2/revoke endpoint.

[dudedad]

IMHO... there should be the capability to set a exp on a refresh token.
Okta does it nicely where you can define the AT to expire after "X" seconds/minutes/days and the RT to expire after "Z" s/m/d but to automatically expire the RT earlier if there has not been any activity (of the AT) in "Y" s/m/d

[jochumdev]

+1

[aeneasr]

I'm not sure, there isn't really a reason for doing that, let me explain:

You're probably coming from an angle where limiting credentials' lifetimes is seen as a security feature. I agree. The thing is, there is not much upside to introducing a lifespan to refresh tokens. Here's would we gain if refresh tokens expire after some time:

1. The application is unable to refresh the token and requests re-authorization from the user.
2. The user performs the oauth2 dance but because the application is already authorized is not shown the consent screen. Maybe the user has to re-authenticate but that's not something we really care about in wrt to the 3rd party app as an oauth2 provider.

The re-authorization process (consent) is skipped because the user already granted consent. If the user was to actually click the permissions, that can only be because prompt was set or because we revoked the application's access. In the latter case, all access and refresh tokens are invalidated anyways.

There is the case where consent is not remembered. This is the only interaction where I think expiring refresh tokens make sense. You would basically need to re-authorize an app after a certain period, but it's also a bit strange because what's the reference? Just because you didn't use an app for a three days, do you have to reauthorize? Why is this requirement not valid if you use the app every day? What's the difference?

To conclude, I understand the desire, but I doubt it's usefulness.

edit:// And please no +1, we're past that with github issue reactions!

[jochumdev]

I see an use case for it.

Let's say an user of Hydra created a SPA where the SPA Logs the user in, the refresh_token will then be saved in the browsers local store, as a security measure i want to enforce re-authorization with the Authorization Server periodically.

I know Hydra also saves data in a cookie, but this is another case.

Hope you see my reasoning,

René

[aeneasr]

As a consumer of the API you can voluntarily do that with prompt=login. Alternatively, you can use the implicit flow with e.g. hidden iframe refresh to achieve the same. Or you use a small proxy that stores the tokens in a httpOnly + secure cookie, mitigating risk of XSS.

[aeneasr]

I'm closing this here and am tracking it in fosite: ory/fosite#319

[aeneasr]

I've added this feature in fosite and will enable it in hydra next: ory/fosite#337