Ability to limit offline access time

[synclpz]

Is your feature request related to a problem? Please describe.

I need a way to limit offline_access time on a mobile app client. So user will be required to make consent again (in a month, for example). From client's point of view it should just be like an expired refresh_token.

Describe the solution you'd like

I need refresh tokens for a specific client to become expired at specific point in time (given from consent app) instead of each new one having expiration time systime + ttl.refresh_token at each refresh action.

Describe alternatives you've considered

1. I tried to use external scheduler to invoke DELETE /oauth2/auth/sessions/consent?subject=user&client=app to force an app to re-authenticate, but this forces all app instances associated with the same client_id to require re-authentication.
2. To fix this it is possible to register each and every mobile app install as a public client through dynamic registration, but this seems to be not feasible due to millions of app installs and ops problems related.

Additional context

At the time of filing this issue Hydra 1.10.1 allows only this flow:

Mobile app (public client) requests user login through Hydra, then it gets access_token and refresh_token, which it uses to update access_token every N minutes. Refresh token is valid, e.g. for a month. Each time an app refreshes an access_token it gets a new refresh_token, which is valid for an extra month from the point of refresh time. So, the app has a chance to use my API without user need to prove her identity if user opens mobile app at least monthly.

What I need is to limit usage of refresh_token by this exact app instance to a fixed time duration from user login time (e.g. 3 months) and then require the app to request user to login (and maybe consent) again.

Perfect solution could have been some coupling refresh_token TTL to an exact point in time instead of a duration from refresh time, so first refresh_token is valid till May 16th, some next, obtained tomorrow still be valid till May 16th, and on May 16th the app gets "already expired" refresh token/error on refreshing and opens a browser with an /auth page again.

[synclpz]

Discussed here https://ory-community.slack.com/archives/C012RBW0F18/p1618509467183800

[synclpz]

Exact same scenario is desribed in a draft of browser-based app (SPA) security considerations while using refresh tokens here https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-07#section-8

Additional information on the topic could be found here https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/ (that is for SPA's, not mobile native apps but nevertheless useful)

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneous you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[aeneasr]

This is still a useful feature request

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️