Big +1 here. I'd be in favor of the document discussing the potential
benefits of tying the refresh token to a session in some situations but
very much agree that the spectrum of desired behaviors is much too wide to
normatively recommend any particular option.
On Wed, Nov 28, 2018 at 11:19 PM
Agreed. Consider also service account flows such as the JWT-bearer approach
used by Google:
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#authorizingrequests
It’s not clear there is any session at all in these cases. (Although I don’t
think there is a refresh token in
I think we need to be very careful about prescribing behavior around refresh
token lifetime, and setting expectations for what degree of consistency is
attainable. Considering the terms "session", "authenticated session",
"offline", "expiration", "termination", and "log out" can mean different
Apologies, I may be speaking out of turn by not fully understanding the use
cases that this thread may be focused on. I’m interpreting the conclusions you
are proposing as general recommendations rather than addressing a specific case.
IMO the biggest general value of refresh is a periodic
> Am 28.11.2018 um 16:53 schrieb George Fletcher :
>
> On 11/28/18 5:11 AM, Torsten Lodderstedt wrote:
>> Hi George,
>>
>>> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>>>
>>> Thanks for the additional section on refresh_tokens. Some additional
>>> recommendations...
>>>
>>> 1. By
Hi George,
> Am 20.11.2018 um 23:38 schrieb George Fletcher :
>
> 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
All important points. I'm not sure it affects whether refresh_tokens
should be bound to the authenticated session or not. If using a
continuous authentication model, it just means that as long as the AS/OP
believes the authentication session is valid, the refresh_token will
also continue to be
> On Nov 20, 2018, at 1:37 PM, Aaron Parecki wrote:
>
> 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
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
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
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
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
12 matches
Mail list logo