IETF Logo Mail Archive

Re: [OAUTH-WG] Refresh tokens

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 22 July 2019 12:12 UTC

Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2A120270 for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 05:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbQ01STYNdSl for <oauth@ietfa.amsl.com>; Mon, 22 Jul 2019 05:12:39 -0700 (PDT)
Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [134.119.228.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C9912009C for <oauth@ietf.org>; Mon, 22 Jul 2019 05:12:39 -0700 (PDT)
Received: from [84.158.229.114] (helo=[192.168.71.123]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <torsten@lodderstedt.net>) id 1hpXBE-0004ZL-3U; Mon, 22 Jul 2019 14:12:36 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <A58E8781-CD67-4B2D-BAD0-05838B3D0D32@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_214C7338-30B2-4B47-B3BB-DE220F5C778E"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 22 Jul 2019 14:12:35 +0200
In-Reply-To: <A5B27EDC-CACD-446D-B98D-85ABC61A6EEE@forgerock.com>
Cc: David Waite <david@alkaline-solutions.com>, OAuth WG <oauth@ietf.org>
To: Neil Madden <neil.madden@forgerock.com>
References: <CABw+FcsH3CHmFphz5DD6aDeEqKLxbQhY14kdrXCVY0WXQN6PuQ@mail.gmail.com> <AEC7268A-D22D-41DA-8609-E7D2DD3B290C@alkaline-solutions.com> <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <CAGBSGjp8m+V+i-sNnrLmu7DR_Bo1uv0iGkW2o7hiqUWw8Sc7qg@mail.gmail.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <CAGBSGjq=SFG5nfOA6nwRsEQY576dsJDAHaL9UH4Yh7AAtOMu5Q@mail.gmail.com> <D676DDDE-20FE-4004-8E3F-124A560A1C20@mit.edu> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <CABw+Fcus9e5Et5aU_70tJwoX5BVfWaFbiJ+f4UgKe2zr46UPvQ@mail.gmail.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> <A5B27EDC-CACD-446D-B98D-85ABC61A6EEE@forgerock.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/C1LG-XZ3k9xMZYD3gko9ukGEYVk>
Subject: Re: [OAUTH-WG] Refresh tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 12:12:42 -0000

Hi Neil,

> On 22. Jul 2019, at 13:59, Neil Madden <neil.madden@forgerock.com> wrote:
> 
>> In addition, a public client which does not use its refresh token in an “offline” manner may have theft go unnoticed for a considerable period of time, and the operational model of public clients usually puts detection of local token theft in the hand of the end user and client software, not an administrator or organizational security staff.
> 
> Given that a refresh token has to be used at the AS, isn't the situation here *better* for refresh tokens? Every time an attacker uses a stolen refresh token you get a nice ping against your centralised token endpoint, giving you a great opportunity to run contextual checks to decide if something looks fishy. 

I agree with your assessment. 

That why the Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.12) requires authorisation servers to detect refresh token replay. Even if the refresh token cannot be sender constraint, one-time refresh tokens (or refresh token rotation) is a viable option when used in combination with conditional revocation of the active refresh token if something looks fishy.

kind regards,
Torsten.

v2.46.0 | Report a Bug | By Email | System Status