On Tue, Nov 20, 2018, 2:56 PM <oauth-requ...@ietf.org wrote:
> Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > Today's Topics: > > 1. Re: I-D Action: draft-ietf-oauth-security-topics-10.txt > (Aaron Parecki) > 2. Re: Refresh Token Expiration (George Fletcher) > 3. Re: Refresh Token Expiration (Aaron Parecki) > > > > ---------- Forwarded message ---------- > From: Aaron Parecki <aa...@parecki.com> > To: Torsten Lodderstedt <tors...@lodderstedt.net> > Cc: OAuth WG <oauth@ietf.org> > Bcc: > Date: Tue, 20 Nov 2018 12:37:34 -0800 > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-10.txt > The new section on refresh tokens is great! I have a couple > questions/comments about some of the details. > > Authorization servers may revoke refresh tokens automatically in case >> of a security event, such as: >> o logout at the authorization server > > > This doesn't sound like the desired behavior for mobile apps, where the > user's expectation of how long they are logged in to the mobile app is not > tied to their web session where they authorized the app. However this does > likely match a user's expectation when authorizing a browser-based app. > Should this be clarified that it should not apply to the mobile app case, > or only apply to browser-based apps? > > Refresh tokens should expire if the client has been inactive for some time > > > This is a good suggestion, but I think it would benefit from a little more > clarity. Specifically pointing out that what counts as "activity" is use of > the access token and/or refresh token, if that's the intention. That will > help avoid confusion that "inactivity" may be referring to the user's > session at the authorization server. > > Is this supposed to be a capital "SHOULD" or lowercase "should"? > > It is also unclear whether this is meant to apply to public clients, > private clients, or both, as well as whether it should apply to mobile apps > or browser-based apps or both. I am curious what the intent is here, since > I feel like that can have some serious implications for the user experience > in some cases and is worth pointing out. > > Lastly, minor nit, I see the comment about changing occurrences of "SHALL" > to "MUST", but the new refresh token section still has two uses of "SHALL". > > Thanks! Overall I'm happy to see this guidance! > > ---- > Aaron Parecki > aaronparecki.com > > > > On Tue, Nov 20, 2018 at 11:33 AM Torsten Lodderstedt < > tors...@lodderstedt.net> 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 >> > > > > ---------- Forwarded message ---------- > From: George Fletcher <gffle...@aol.com> > To: Torsten Lodderstedt <tors...@lodderstedt.net>, oauth@ietf.org > Cc: > Bcc: > Date: Tue, 20 Nov 2018 15:37:57 -0500 > Subject: Re: [OAUTH-WG] Refresh Token Expiration > Hi Torsten, > > This is the module I much prefer. By default all refresh_tokens are bound > to the user's authenticated session. When the authentication session is > terminated, the refresh_tokens are invalidated. If a client wants to get a > refresh_token that is NOT bound to an authentication session, then it much > explicitly request the "offline_access" scope which then provides a consent > interaction with the user which allows the user to know that this client > wants to access their resources even when the user isn't logged in > (present). This also provides the AS with the ability to control which > clients are authorized to request "offline_access" and hence restrict that > capability to know/approved clients. > > We've implemented this module in two different Authorization Servers. > > Thanks, > George > > On 11/15/18 9:28 AM, Torsten Lodderstedt wrote: > > Hi all, > > I‘m preparing a new section on Refresh Token best practices for the Security > BCP. I‘m wondering whether anyone has implemented a binding of the refresh > token‘s expiration/revocation with the state of the session the refresh token > was issued in/for. So do you revoke refresh tokens when the user logs out > from the AS or the session terminated for other reasons? > > kinds regards, > Torsten. > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > > ---------- Forwarded message ---------- > From: Aaron Parecki <aa...@parecki.com> > To: gffletch=40aol....@dmarc.ietf.org > Cc: Torsten Lodderstedt <tors...@lodderstedt.net>, OAuth WG < > oauth@ietf.org> > Bcc: > Date: Tue, 20 Nov 2018 12:56:13 -0800 > Subject: Re: [OAUTH-WG] Refresh Token Expiration > Hi George, > > Reading this description, am I understanding correctly that you *always* > return a refresh token to every client? Are there any situations in which a > refresh token would not be returned? Specifically I'm wondering about how > this applies to browser-based apps using the authorization code flow and > refresh tokens. > > ---- > Aaron Parecki > aaronparecki.com > > > > On Tue, Nov 20, 2018 at 12:38 PM George Fletcher <gffletch= > 40aol....@dmarc.ietf.org> wrote: > >> Hi Torsten, >> >> This is the module I much prefer. By default all refresh_tokens are bound >> to the user's authenticated session. When the authentication session is >> terminated, the refresh_tokens are invalidated. If a client wants to get a >> refresh_token that is NOT bound to an authentication session, then it much >> explicitly request the "offline_access" scope which then provides a consent >> interaction with the user which allows the user to know that this client >> wants to access their resources even when the user isn't logged in >> (present). This also provides the AS with the ability to control which >> clients are authorized to request "offline_access" and hence restrict that >> capability to know/approved clients. >> >> We've implemented this module in two different Authorization Servers. >> >> Thanks, >> George >> >> On 11/15/18 9:28 AM, Torsten Lodderstedt wrote: >> >> Hi all, >> >> I‘m preparing a new section on Refresh Token best practices for the Security >> BCP. I‘m wondering whether anyone has implemented a binding of the refresh >> token‘s expiration/revocation with the state of the session the refresh >> token was issued in/for. So do you revoke refresh tokens when the user logs >> out from the AS or the session terminated for other reasons? >> >> kinds regards, >> Torsten. >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://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
