Return-Path: 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 A9CE9120265 for ; Mon, 22 Jul 2019 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com 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 JneV1p3MGuRF for ; Mon, 22 Jul 2019 04:59:19 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D704120256 for ; Mon, 22 Jul 2019 04:59:19 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id a15so34861778wmj.5 for ; Mon, 22 Jul 2019 04:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=74ww72g7dktt1IU6jtuCC6SdpQPmx2/V071qDZpiGYw=; b=Zk7rlgV9MNkXWMfI+Cxkbt3RQ64fIXBg6aoyMyvQhVp4zRLgZ3p8I7yXBIQqT8U71B 9xYQNW3d3Nf3paggepsMPUcr2Jj8IX1PrI1vCtiWyIHDrWS9uwV/ChsvHgS242Oot8av 7K6cNtZf3nPXYrar7X4esg+jy6qqigEvZV2qk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=74ww72g7dktt1IU6jtuCC6SdpQPmx2/V071qDZpiGYw=; b=SdzGhkLQIIhXOJ5kUxvFzpA9lbROivC/LFoN2HAkh23iIA3aPsPuXKFnMmMVbBf6Je Xx52Xe6Y9oIz18vqtAlfw3K8EoUTKFkZoSsCe3NZZMhzdvwiChu8aK6ZuOQC2lgXb169 RhovH/nlWzVcYBbEkrrHMc6SodxrDUOtg5LUK1qpKXHu7fzhb4h0L9UIjK0axdmlMRpS 8ulKz7Wfo8bkpyG2dYF95tfV5x6vIK692lSVxrL8Q8rcyRpsW/UfWThV7v8E9FJicYIk WGDyeduriqcWYTV+LDaaK2ZYdesmPZMw+W3pMi1n2fu4+6sSQzFAkla5+Tvfb+iPfcww GEsg== X-Gm-Message-State: APjAAAXwfbuVnrmF+NPvBJHUK8EsOpg43DwGYCtQ36P+OIWOtIqSV8Sz CLwRQTGNWpDzaopUkxuW1B0X1g== X-Google-Smtp-Source: APXvYqyl3PtJkbL17Ye0Xuhsp09sfZG69X7Zd88dkQv+yA6PmRMjQzLOTzUXfyG+EoLU+LDRvlz8jA== X-Received: by 2002:a7b:c149:: with SMTP id z9mr65797898wmi.0.1563796757506; Mon, 22 Jul 2019 04:59:17 -0700 (PDT) Received: from [192.168.1.64] (98.87.75.194.dyn.plus.net. [194.75.87.98]) by smtp.gmail.com with ESMTPSA id n8sm30588467wro.89.2019.07.22.04.59.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jul 2019 04:59:16 -0700 (PDT) From: Neil Madden Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 22 Jul 2019 12:59:13 +0100 In-Reply-To: <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> Cc: Leo Tohill , OAuth WG To: David Waite References: <624da319-b19c-053b-4fd0-048c0e2b8fb9@aol.com> <138cbde0-11b7-8f23-1028-3af0846b5a01@aol.com> <0A6F7761-9376-43EE-9B9C-0554812E13B7@forgerock.com> <20C9E1B6-E497-41C9-9590-F68DD747E401@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [OAUTH-WG] Refresh tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 11:59:23 -0000 --Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you both for your replies, my responses are below: On 20 Jul 2019, at 19:54, David Waite = wrote: >=20 >> On Jul 20, 2019, at 12:38 PM, Leo Tohill wrote: >>=20 >> Access tokens and refresh tokens, stored browser-side, are equally = vulnerable to theft, because the storage options are identical.=20 >>=20 >> We are more concerned about the theft of the refresh token, because = it (commonly) has a longer usable lifetime than the access token.=20 >>=20 >> Still , its a matter of degree. Since we accept the risk of access = token theft, why can't we accept the risk of refresh token theft? We = ameliorate the access token risk by using short lifetimes, but there is = no standard for that value: it is situational. Why doesn't the same = reasoning apply to refresh tokens?=20 >>=20 >> This reasoning assumes that refresh tokens also have a limited = lifetime. I am unsure that this is always the case. When one uses a = refresh token to acquire a new access token, AND that operation issues a = new refresh token, does the new refresh token get a new lifetime? If = so, then a refresh token can be used to retain access infinitely (or = until it is revoked server-side). In this scenario, the risks = associated with browser-side storage of refresh token are much higher.=20= >>=20 >> In summary, I'd say that IF the lifetime of a refresh token can be = limited, then refresh tokens pose identical risk as access tokens, and = so the same considerations apply.=20 >=20 > Agreed >=20 > I think there is an unwritten framework for evaluating the security of = all tokens, regardless of type. For example: access tokens are shared = with resources, so their security protections in the Security BCP = including limiting replay against other resources, and optionally = against new requests against the same resource. >=20 > Because it is complex and unwritten, it is hard to do a true = evaluation. My impression was always that refresh tokens were more = =E2=80=98risky=E2=80=99 for public clients because =E2=80=9Coffline=E2=80=9D= refresh tokens may be good for an indeterminate period of time, and = because lack of credentials means theft of the token is sufficient. Access tokens (without PoP) are also usable without credentials, so this = is not a reason why refresh tokens are more risky. =46rom the responses, = it appears that token lifetime is the primary concern - access tokens = usually have a limited lifespan but refresh tokens are unlimited. But = there are very few threats that are eliminated by short token lifetimes. = For example, when somebody goes for a coffee leaving their computer or = phone unlocked. But even in these cases you are normally concerned with = idle-timeouts rather than overall token lifetime. The token should = become invalid after 3 minutes of inactivity, for example. > In addition, a public client which does not use its refresh token in = an =E2=80=9Coffline=E2=80=9D 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.=20 >=20 > But those concerns are mostly mitigated if the OP can set policy to = control refresh token usage in concert with the authentication session. I'm not sure that OAuth should tie itself to a concept of authentication = session. Would it be better to say that all tokens issued to = browser-based clients should have a short idle timeout? There's also a privacy aspect to linking refresh tokens to a user's = authentication session, as it gives the 3rd-party client a way to detect = when you are/are not logged into Facebook or whatever. That may be = desirable in some cases, but not necessarily always.=20 -- Neil= --Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you both for your replies, my responses are = below:

On 20 Jul 2019, at = 19:54, David Waite <david@alkaline-solutions.com> wrote:

On = Jul 20, 2019, at 12:38 PM, Leo Tohill <leotohill@gmail.com>= wrote:

Access tokens and refresh tokens, = stored browser-side, are equally vulnerable to theft, because the = storage options are identical. 

We are more concerned about the theft of the refresh token, = because it (commonly) has a longer usable lifetime than the access = token. 

Still , its a matter of degree. Since we = accept the risk of access token theft,  why can't we accept the = risk of refresh token theft?  We ameliorate the access token risk = by using short lifetimes, but there is no standard for that value: it is = situational.  Why doesn't the same reasoning apply to refresh = tokens? 

This reasoning assumes that refresh tokens = also have a limited lifetime.  I am unsure that this is always the = case.  When one uses a refresh token to acquire a new access token, = AND that operation issues a new refresh token, does the new refresh = token get a new lifetime?  If so, then a refresh token can be used = to retain access infinitely (or until it is revoked server-side). =  In this scenario, the risks associated with browser-side storage = of refresh token are much higher. 

In summary, I'd say that IF the lifetime of a refresh token = can be limited, then refresh tokens pose identical risk as access = tokens, and so the same considerations apply. 

Agreed

I think there is an unwritten framework for evaluating the = security of all tokens, regardless of type. For example: access tokens = are shared with resources, so their security protections in the Security = BCP including limiting replay against other resources, and optionally = against new requests against the same resource.

Because it is = complex and unwritten, it is hard to do a true evaluation. My impression = was always that refresh tokens were more =E2=80=98risky=E2=80=99 for = public clients because =E2=80=9Coffline=E2=80=9D refresh tokens may be = good for an indeterminate period of time, and because lack of = credentials means theft of the token is sufficient.

Access= tokens (without PoP) are also usable without credentials, so this is = not a reason why refresh tokens are more risky. =46rom the responses, it = appears that token lifetime is the primary concern - access tokens = usually have a limited lifespan but refresh tokens are unlimited. But = there are very few threats that are eliminated by short token lifetimes. = For example, when somebody goes for a coffee leaving their computer or = phone unlocked. But even in these cases you are normally concerned with = idle-timeouts rather than overall token lifetime. The token should = become invalid after 3 minutes of inactivity, for example.

In addition, = a public client which does not use its refresh token in an =E2=80=9Cofflin= e=E2=80=9D 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. 


But those concerns are mostly mitigated if the OP can set = policy to control refresh token usage in concert with the authentication = session.

I'm not sure = that OAuth should tie itself to a concept of authentication session. = Would it be better to say that all tokens issued to browser-based = clients should have a short idle timeout?

There's also a privacy aspect to linking refresh = tokens to a user's authentication session, as it gives the 3rd-party = client a way to detect when you are/are not logged into Facebook or = whatever. That may be desirable in some cases, but not necessarily = always. 

-- = Neil
= --Apple-Mail=_25411862-9AF1-4E47-93B5-41884CBE7995--