Re: [OAUTH-WG] expires_in

Neil Madden <> Tue, 18 December 2018 09:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 647B01310E7 for <>; Tue, 18 Dec 2018 01:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rNfj3EcelHdP for <>; Tue, 18 Dec 2018 01:42:38 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75BA7130E66 for <>; Tue, 18 Dec 2018 01:42:38 -0800 (PST)
Received: by with SMTP id u4so14190453wrp.3 for <>; Tue, 18 Dec 2018 01:42:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1Lf5ZxM7w+sNrMGqaKA9UVzS4K8lb1t8dZU7l/NRKu4=; b=MEi0haBzNGW37R/joNMQrk4ZUQ1S22JKgFOPZKFIA2z4gxaK31bP8Pz3UcIm+5YJHP IoxIS9JP6hGGjNFQYlJtK7130rM9sYvi7nBqUwszlfrPltRxFQOl3k6Tm5/i2aOQ4E8F NLZdvD9Uqj5Y5Ao/kmsMJpzTjXzpdEelDwHPA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1Lf5ZxM7w+sNrMGqaKA9UVzS4K8lb1t8dZU7l/NRKu4=; b=ZmIQqbPAhnbTrQKogybqM2PTTDkxy0RYSKlUS3Y0nWlFl+pUoNlsAWeALoY4SW4GVi rGSp9mV2Hle2z9iloL0fVaYGOvllAfDrpqJaUiX8lYp9SzyKx7TfLm3S7rgCAj2oA/DU /1DPrycWc0CvYE29tTLSTFXj188b5eINKOfEelBZNy08KURh+gu4TPFVeMuo2jZl2uBZ jlM+HrZdP/6uUVf0q+DoDeNxg/PrG2Gf4vJzlW/e+xbp5b9LrRMzQWxVGrab+Y7HDxd4 o+4jeLjwoHVfKgDDV3IDzYLhbgl3/G5+TL3D9SaM+Jg2oo2pGdk3BMd8aet1gmWtCk4K yh6Q==
X-Gm-Message-State: AA+aEWb6uXW4hB7iIJK9OQ4hIiTBXDRgQjmhgror/9B3oCAuoRqqklva 4Dpdc1pIZQdkYYLSp1n/OGL1jQ==
X-Google-Smtp-Source: AFSGD/U+Af82RQdxO93WruNIjEGaSPYXALqfh3dGzzAKHjkLWyfVJjnBvwNJ5m9RWsgtFF3ZqxWXrQ==
X-Received: by 2002:a5d:4586:: with SMTP id p6mr13538832wrq.69.1545126156643; Tue, 18 Dec 2018 01:42:36 -0800 (PST)
Received: from guest2s-mbp.lan ( []) by with ESMTPSA id h62sm1472878wmf.11.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 01:42:35 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Neil Madden <>
In-Reply-To: <>
Date: Tue, 18 Dec 2018 09:42:34 +0000
Cc: oauth <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Hannes Tschofenig <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [OAUTH-WG] expires_in
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: Tue, 18 Dec 2018 09:42:42 -0000

This is probably a best practice, but we should be careful to not oversell the benefits. Unless you measure token lifetime in a small number of seconds, then it’s doubtful that any realistic attack will be stopped by this. It’s mostly useful at defending against opportunistic attacks - e.g. a token accidentally gets logged, but the logs aren’t examined very often. Sender-constrained/PoP tokens, avoiding passing tokens in URL parameters, and so on are better defences against this kind of thing.

There are two deployment scenarios when short-lived access token are essential though:

1. If you are employing the “self-contained RS” model (no introspection calls to the AS) and are using short-lived access tokens with a refresh token to force the client to check in with the AS periodically to allow token revocation. [1]

2. If you are using a blacklisting strategy to token revocation, in which case having a short token lifetime limits the amount of time you need to blacklist tokens for.

On the other hand, is there ever a valid reason for having an access token be valid for 10 years or so?


— Neil

> On 18 Dec 2018, at 08:55, Hannes Tschofenig <> wrote:
> Hi all,
> In a recent email conversation on the IETF ACE mailing list Ludwig Seitz suggested that the expires_in claim in an access token should actually be mandatory.
> Intuitively it feels like access tokens shouldn't have an unrestricted lifetime. I am curious whether recommendations would be useful here.
> RFC 6819 talks about the expires_in claim and says:
> 3.1.2.  Limited Access Token Lifetime
>   The protocol parameter "expires_in" allows an authorization server
>   (based on its policies or on behalf of the end user) to limit the
>   lifetime of an access token and to pass this information to the
>   client.  This mechanism can be used to issue short-lived tokens to
>   OAuth clients that the authorization server deems less secure, or
>   where sending tokens over non-secure channels.
> draft-ietf-oauth-security-topics-10 only talks about refresh token expiry.
> In OpenID Connect the expires_in claim is also optional.
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list