Agreed. Consider also service account flows such as the JWT-bearer approach used by Google: https://developers.google.com/identity/protocols/OAuth2ServiceAccount#authorizingrequests
It’s not clear there is any session at all in these cases. (Although I don’t think there is a refresh token in this specific case). I think spectrum of desired behaviours is too wide to recommend any particular option. Perhaps tying the refresh token to a session could be included as a MAY just to document it as something to consider? — Neil > On 29 Nov 2018, at 00:20, Richard Backman, Annabelle > <richanna=40amazon....@dmarc.ietf.org> wrote: > > 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" > <oauth-boun...@ietf.org on behalf of tors...@lodderstedt.net> wrote: > > > >> Am 28.11.2018 um 16:53 schrieb George Fletcher <gffle...@aol.com>: >> >> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote: >>> Hi George, >>> >>>> Am 20.11.2018 um 23:38 schrieb George Fletcher <gffle...@aol.com>: >>>> >>>> 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 internet-dra...@ietf.org >>>>>> : >>>>>> >>>>>> >>>>>> 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 >>>>>> >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
