New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: specify lifespan for refresh_token #1088

Closed
fredbi opened this Issue Oct 11, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@fredbi

fredbi commented Oct 11, 2018

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 comment has been minimized.

Member

aeneasr commented Oct 11, 2018

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

This comment has been minimized.

dudedad commented Oct 12, 2018

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

@pcdummy

This comment has been minimized.

pcdummy commented Oct 12, 2018

+1

@aeneasr

This comment has been minimized.

Member

aeneasr commented Oct 12, 2018

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!

@pcdummy

This comment has been minimized.

pcdummy commented Oct 18, 2018

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

This comment has been minimized.

Member

aeneasr commented Oct 18, 2018

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

This comment has been minimized.

Member

aeneasr commented Oct 25, 2018

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

@aeneasr aeneasr closed this Oct 25, 2018

@nerocrux nerocrux referenced this issue Nov 10, 2018

Merged

do omit exp if ExpiresAt is zero value #334

5 of 5 tasks complete
@aeneasr

This comment has been minimized.

Member

aeneasr commented Nov 16, 2018

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

aeneasr added a commit that referenced this issue Nov 16, 2018

vendor: Upgrade to fosite 0.28.0
This patch enables refresh token expiry.

Closes #1088

Signed-off-by: arekkas <aeneas@ory.am>

aeneasr added a commit that referenced this issue Nov 16, 2018

vendor: Upgrade to fosite 0.28.0
This patch enables refresh token expiry.

Closes #1088

Signed-off-by: arekkas <aeneas@ory.am>

aeneasr added a commit that referenced this issue Nov 16, 2018

vendor: Upgrade to fosite 0.28.0 (#1172)
This patch enables refresh token expiry.

Closes #1088

Signed-off-by: arekkas <aeneas@ory.am>

aeneasr added a commit that referenced this issue Nov 18, 2018

vendor: Upgrade to fosite 0.28.0 (#1172)
This patch enables refresh token expiry.

Closes #1088

Signed-off-by: arekkas <aeneas@ory.am>

aeneasr added a commit that referenced this issue Nov 18, 2018

vendor: Upgrade to fosite 0.28.0 (#1172)
This patch enables refresh token expiry.

Closes #1088

Signed-off-by: arekkas <aeneas@ory.am>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment