> 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
