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. > 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? > 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). 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
