Re: [OAUTH-WG] First Draft of OAuth 2.1

[Neil Madden <[e-mail]>]

We have had several customers express interest in sliding expiration (idle timeouts) of refresh tokens and push back against rotation, particularly for mobile apps where they worry that the false positive rate with rotation can be too high to be practical due to flaky network connections. 

Neil

> On 13 Mar 2020, at 08:47, Dominick Baier <[e-mail]> wrote:
> 
> 
> Off the top of my head, rotation is useful for 2 things
> 
> * reducing the likelihood that an “old” refresh token is still valid (e.g. “found” on some device, log file, source code etc...)
> * being able to revoke all the active refresh tokens if a refresh token is used twice
> 
> ..and yes it introduces a higher chance of false positives.
> 
> https://leastprivilege.com/2020/01/21/hardening-refresh-tokens/
> 
> But I agree with the spec - if the refresh token cannot be bound to a client by a secret (looking at you, SPAs) - it should be hardened using sliding expiration, rotation and replay detection. Maybe the wording needs to be clearer.
> 
> ———
> Dominick Baier
> 
>> On 12. March 2020 at 23:15:19, Vittorio Bertocci (vittorio=[e-mail]) wrote:
>> 
>> Rotation can be used to detect leakage, right? Client credentials offer more guarantees, but unless you are using private JWTs with a non exportable certificate as client cred, a classic client secret _could_ technically leak. Having rotation would alert you if someone got a hold on those. Admittedly it’s a stretch, but not entirely inconceivable.
>> 
>>> On Thu, Mar 12, 2020 at 13:57 Torsten Lodderstedt <torsten=[e-mail]> wrote:
>>> Then why are you rotating refresh tokens? 
>>> 
>>>>> Am 12.03.2020 um 20:48 schrieb Pedro Igor Silva <psilva@redhat..com>:
>>>>> 
>>>> 
>>>> A confidential client, as per the `web application` definition in Section `2.1.  Client Types`.
>>>> 
>>>>> On Thu, Mar 12, 2020 at 4:39 PM Torsten Lodderstedt <[e-mail]> wrote:
>>>>> Is that a public client?
>>>>> 
>>>>>>> Am 12.03.2020 um 20:32 schrieb Pedro Igor Silva <[e-mail]>:
>>>>>>> 
>>>>>> 
>>>>>> I agree with you and recently, we had to deal with an issue where a `web application` using rotation (as defined by the draft) was having issues to refresh tokens due to multiple concurrent requests at the moment a token is about to expire or already expired.. We had to add some controls to deal with concurrency and additional complexity + performance penalties. And for such clients, I was not sure whether or not rotation makes sense.
>>> 
>>>>>> 
>>>>>>> On Thu, Mar 12, 2020 at 4:05 PM Vittorio Bertocci <Vittorio=[e-mail]> wrote:
>>>>>>> Thanks for the clarification, Torsten.
>>>>>>> I believe it's the first time I see use of client credentials positioned as sender constraint; if the intent is saying that confidential clients should use their credentials when redeeming refresh tokens, I am of course in agreement but I think the language should be clearer and state the above explicitly.
>>>>>>> 
>>>>>>> Re: failure frequency, I know of scenarios were the designers added rotation by default, and after a while it was turned to opt in because of the frequency of errors and impact on user experience/call center.
>>>>>>> I really believe that putting this as a MUST is justified only for exceedingly vulnerable situations, like SPAs.
>>>>>>> Native/desktop clients should be free to decide whether they want to opt in without loosing compliance. Just my 2 C
>>>>>>> 
>>>>>>>> On Thu, Mar 12, 2020 at 11:58 AM Torsten Lodderstedt <torsten=[e-mail]> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> sender constraining refresh tokens for confidential client means client authentication + check the binding of the refresh token with the respective client id. I don’t think this is new as RFC6759 already required ASs to check this binding. Assuming backends are generally confidential clients also means no rotation and no cache synchronization needed.
>>>>>>>> 
>>>>>>>> Rotation should be used for frontends, e.g. native apps and only if there is there no other option. If a refresh fails, the app must go through the authorization process again. That’s inconvenient so the question is how often this happens. What I can say, I have never seen customer complaining in several years of operation of ASs with refresh token rotation (including replay detection) for native apps with millions of users.
>>>>>>>> 
>>>>>>>> best regards,
>>>>>>>> Torsten.
>>>>>>>> 
>>>>>>>>>> Am 12.03..2020 um 19:24 schrieb Vittorio Bertocci <Vittorio=[e-mail]..org>:
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Hey guys,
>>>>>>>>> thanks for putting this together.
>>>>>>>>> I am concerned with the real world impact of imposing sender constraint | rotation as a MUST on refresh tokens in every scenario.
>>>>>>>>> Sender constraint isn't immediately actionable - we just had the discussion for dPOP, hence I won't go in the details here.
>>>>>>>>> Rotation isn't something that can be added without significant impact on development and runtime experiences:
>>>>>>>>> on distributed scenarios, it introduces the need to serialize access to shared caches
>>>>>>>>> network failures can lead to impact on experience- stranding clients which fail to receive RTn+1 during RTn redemption in a limbo where user interaction might become necessary, disrupting experience or functionality for scenarios where the user isn't available to respond.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <aaron@parecki..com> wrote:
>>>>>>>>>> I'm happy to share that Dick and Torsten and I have published a first
>>>>>>>>>> draft of OAuth 2.1. We've taken the feedback from the discussions on
>>>>>>>>>> the list and incorporated that into the draft.
>>>>>>>>>> 
>>>>>>>>>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
>>>>>>>>>> 
>>>>>>>>>> A summary of the differences between this draft and OAuth 2.0 can be
>>>>>>>>>> found in section 12, and I've copied them here below.
>>>>>>>>>> 
>>>>>>>>>> > This draft consolidates the functionality in OAuth 2.0 (RFC6749),
>>>>>>>>>> > OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
>>>>>>>>>> > (RFC7636), OAuth 2.0 for Browser-Based Apps
>>>>>>>>>> > (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
>>>>>>>>>> > Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
>>>>>>>>>> > (RFC6750).
>>>>>>>>>> >
>>>>>>>>>> >   Where a later draft updates or obsoletes functionality found in the
>>>>>>>>>> >   original [RFC6749], that functionality in this draft is updated with
>>>>>>>>>> >   the normative changes described in a later draft, or removed
>>>>>>>>>> >   entirely.
>>>>>>>>>> >
>>>>>>>>>> >   A non-normative list of changes from OAuth 2.0 is listed below:
>>>>>>>>>> >
>>>>>>>>>> >   *  The authorization code grant is extended with the functionality
>>>>>>>>>> >      from PKCE ([RFC7636]) such that the only method of using the
>>>>>>>>>> >      authorization code grant according to this specification requires
>>>>>>>>>> >      the addition of the PKCE mechanism
>>>>>>>>>> >
>>>>>>>>>> >   *  Redirect URIs must be compared using exact string matching as per
>>>>>>>>>> >      Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>>>>>>>>>> >
>>>>>>>>>> >   *  The Implicit grant ("response_type=token") is omitted from this
>>>>>>>>>> >      specification as per Section 2.1.2 of
>>>>>>>>>> >      [I-D.ietf-oauth-security-topics]
>>>>>>>>>> >
>>>>>>>>>> >   *  The Resource Owner Password Credentials grant is omitted from this
>>>>>>>>>> >      specification as per Section 2.4 of
>>>>>>>>>> >      [I-D.ietf-oauth-security-topics]
>>>>>>>>>> >
>>>>>>>>>> >   *  Bearer token usage omits the use of bearer tokens in the query
>>>>>>>>>> >      string of URIs as per Section 4.3.2 of
>>>>>>>>>> >      [I-D.ietf-oauth-security-topics]
>>>>>>>>>> >
>>>>>>>>>> >   *  Refresh tokens must either be sender-constrained or one-time use
>>>>>>>>>> >      as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
>>>>>>>>>> 
>>>>>>>>>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
>>>>>>>>>> 
>>>>>>>>>> I'm excited for the direction this is taking, and it has been a
>>>>>>>>>> pleasure working with Dick and Torsten on this so far. My hope is that
>>>>>>>>>> this first draft can serve as a good starting point for our future
>>>>>>>>>> discussions!
>>>>>>>>>> 
>>>>>>>>>> ----
>>>>>>>>>> Aaron Parecki
>>>>>>>>>> aaronparecki.com
>>>>>>>>>> @aaronpk
>>>>>>>>>> 
>>>>>>>>>> P.S. This notice was also posted at
>>>>>>>>>> https://aaronparecki.com/2020/03/11/14/oauth-2-1
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________ 
>> OAuth mailing list 
>> [e-mail] 
>> https://www.ietf.org/mailman/listinfo/oauth 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth