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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
