Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt

[Brian Campbell <[e-mail]>]

Big +1 here. I'd be in favor of the document discussing the potential
benefits of tying the refresh token to a session in some situations but
very much agree that the spectrum of desired behaviors is much too wide to
normatively recommend any particular option.

On Wed, Nov 28, 2018 at 11:19 PM Neil Madden <[e-mail]>
wrote:

> 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=[e-mail]> 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" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>
>
> Am 28.11.2018 um 16:53 schrieb George Fletcher <[e-mail]>:
>
>
> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>
> Hi George,
>
>
> Am 20.11.2018 um 23:38 schrieb George Fletcher <[e-mail]>:
>
>
> 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 [e-mail]
>
> :
>
>
>
> 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
> <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
>
>
> [e-mail]
>
> https://www..ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
>
> OAuth mailing list
>
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._