I think we need to be very careful about prescribing behavior around refresh token lifetime, and setting expectations for what degree of consistency is attainable. Considering the terms "session", "authenticated session", "offline", "expiration", "termination", and "log out" can mean different things to different services (and those tiny nuances matter!) I am against text that makes binding refresh tokens to the authenticated session a "SHOULD." Rather, we should recommend that the AS provide the end user with a mechanism by which they may terminate refresh tokens. We can also describe session-bound refresh tokens as one such method that may or may not be appropriate depending on the use case.
To back up my claim that consistency is Hard, here are a few scenarios to consider: 1) A mobile app loads the authorization request in an in-app browser tab that has an app-scoped cookie jar and is never presented by the app again after the flow is complete. How does the user sign out of that session? Should the AS kill the session due to inactivity? Won't that confuse the user when suddenly the integration between app and service stops working for no discernable reason? If this scenario sounds unlikely, it's not. This is the behavior of every app that integrated with the Safari in-app browser tab in iOS 9 and never updated to the authentication-oriented replacements introduced later, as well as that of every app that opens the authorization request in a web view (ugh). 2) A mobile app loads the authorization request in the external browser, but the user always uses the AS's app on their device instead of visiting their website (e.g., using the Gmail app instead of going to gmail.com in the browser), so their browser session quickly times out due to inactivity. Again, won't that confuse the user when the client mobile app stops working? 3) A set-top box uses the device flow, and the tokens it receives are bound to the user's session in the web browser on their laptop, where they completed the device flow. The user buys a new laptop, their session on their old laptop times out due to inactivity, and their set-top box can't stream videos anymore. ¯\_(ツ)_/¯ -- Annabelle Richard Backman AWS Identity On 11/28/18, 9:20 AM, "OAuth on behalf of Torsten Lodderstedt" <[email protected] on behalf of [email protected]> wrote: > Am 28.11.2018 um 16:53 schrieb George Fletcher <[email protected]>: > > On 11/28/18 5:11 AM, Torsten Lodderstedt wrote: >> Hi George, >> >>> Am 20.11.2018 um 23:38 schrieb George Fletcher <[email protected]>: >>> >>> Thanks for the additional section on refresh_tokens. Some additional recommendations... >>> >>> 1. By default refresh_tokens are bound to the user's authenticated session. When the authenticated session expires or is terminated (whether by the user or for some other reason) the refresh_tokenis implicitly revoked. >> SHOULD or MUST? I would suggest to go with a SHOULD. > I would say that the AS SHOULD bind the refresh_token to the user's authentication. However, I'd lean more to MUST for session bound refresh_tokens being revoked when the session is terminated. wfm Anyone on the list wanting to object? >> >>> 2. Clients that need to obtain a refresh_token that exists beyond the lifetime of the user's authentication session MUST indicate this need by requesting the "offline_access" scope (https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess). This provides for a user consent event making it clear to the user that the client is requesting access even when the user's authentication session expires. This then becomes the default for mobile apps as the refresh_token should not be tied to the web session used to authorize the app. >> Sounds reasonable, just the scope „offline_access“ is OIDC specific. Is it time to move it down the stack to OAuth? > It may be if we want more consistency in the implementation of refresh_token policy across authorization servers. Who has an opinion on that topic? >> >>> 3. The AS MAY consider putting an upper bound on the lifetime of a refresh_token (e.g. 1 year). There is no real need to issue a refresh_token that is good indefinitely. >> I thought I had covered that in the last section. It’s now: >> >> Refresh tokens SHOULD expire if the client has been inactive for some time, >> i.e. the refresh token has not been used to obtain fresh access tokens for >> some time. The expiration time is at the discretion of the authorization server. >> It might be a global value or determined based on the client policy or >> the grant associated with the refresh token (and its sensitivity). > This is slightly different but sufficient so +1 for the text :) Ok, thanks. >> >> Proposals are welcome! >> >> kind regards, >> Torsten. >> >> >>> This is in addition to the other best practices described. >>> >>> Thanks, >>> George >>> >>> On 11/20/18 2:32 PM, Torsten Lodderstedt wrote: >>>> Hi all, >>>> >>>> the new revision contains the following changes: >>>> >>>> * added section on refresh tokens >>>> * additional justifications for recommendation for code >>>> * refactored 2.1 in order to distinguish CSRF, authz response replay and mix-up (based on feedback by Joseph Heenan) >>>> * added requirement to authenticate clients during code exchange (PKCE or client credential) to 2.1.1. >>>> * changed occurrences of SHALL to MUST >>>> >>>> As always: looking forward for your feedback. >>>> >>>> kind regards, >>>> Torsten. >>>> >>>> >>>>> Am 20.11.2018 um 20:26 schrieb [email protected] >>>>> : >>>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the Web Authorization Protocol WG of the IETF. >>>>> >>>>> Title : OAuth 2.0 Security Best Current Practice >>>>> Authors : Torsten Lodderstedt >>>>> John Bradley >>>>> Andrey Labunets >>>>> Daniel Fett >>>>> Filename : draft-ietf-oauth-security-topics-10.txt >>>>> Pages : 38 >>>>> Date : 2018-11-20 >>>>> >>>>> Abstract: >>>>> This document describes best current security practice for OAuth 2.0. >>>>> It updates and extends the OAuth 2.0 Security Threat Model to >>>>> incorporate practical experiences gathered since OAuth 2.0 was >>>>> published and covers new threats relevant due to the broader >>>>> application of OAuth 2.0. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >>>>> >>>>> >>>>> There are also htmlized versions available at: >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-10 >>>>> >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-10 >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
