Hi Aaron, > Am 20.11.2018 um 21:37 schrieb Aaron Parecki <aa...@parecki.com>: > > 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?
The Security BCP’s is intended to describe threats and potential
countermeasures for implementors. There is such a variety of design option even
within a class of apps, I don’t think we can cover them all. I think this kind
of consideration should go into app type specific BCPs, like your’s.
Nevertheless, if you come up with a concrete text proposal, we can discuss it’s
inclusion.
>
> 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.
You are right. Acivity here means „refresh“. How about this:
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).
>
> Is this supposed to be a capital "SHOULD" or lowercase "should“?
Changed it (see above)
>
> 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.
It’s supposed to by applicable to all sorts of clients. The text explicitly
distinguishes protection mechanisms for public and confidential clients. What
do you miss? Any text proposal is helpful.
>
> 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“.
Fixed it.
>
> Thanks! Overall I'm happy to see this guidance!
Thanks.
kind regards,
Torsten.
>
> ----
> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
