Subject: [OAUTH-WG] expires_in

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Dec 2018 08:55:06 +0000

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.

---

From: Neil Madden <[email-masked]>
Date: Tue, 18 Dec 2018 09:42:34 +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?

[1] https://www.ietf.org/mail-archive/web/oauth/current/msg06687.html

— Neil

> On 18 Dec 2018, at 08:55, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vittorio Bertocci <[email-masked]>
Date: Tue, 18 Dec 2018 02:11:09 -0800

It does sound like a best practice and nearly all the providers I've ever
worked with do have an expiration for ATs, however there are
counterexamples (most notably, dropbox
<https://www.dropbox.com/developers/support#token-expiration>) and they
seem to be doing fine so far.
Do we know anyone on Dropbox that can comment on their use case and whether
they'd see value in changing their current behavior?

On Tue, Dec 18, 2018 at 1:42 AM Neil Madden <[email-masked]>
wrote:

> 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.
>
> 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.
>
> > 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.
> >
> > 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.
> >

---

From: David Waite <[email-masked]>
Date: Tue, 18 Dec 2018 06:59:07 -0500

My understanding was that this parameter was advisory to the client - it neither mandated the client discard the token after the expires_in time, nor has a requirement that the token is no longer honored by protected resouces at that point in time (vs earlier or later).

Is there meaning that others assign to this value? The only use I’ve found is to schedule proactive refreshes to hopefully reduce latency by reducing the need to refresh in-line with user requests.

-DW

> On Dec 18, 2018, at 3:55 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 18 Dec 2018 13:17:55 +0100

On 18/12/2018 12:59, David Waite wrote:
> My understanding was that this parameter was advisory to the client -
> it neither mandated the client discard the token after the expires_in
> time, nor has a requirement that the token is no longer honored by
> protected resouces at that point in time (vs earlier or later).

That is my understanding as well, I would however have expected that 
this parameter would be aligned with the 'exp' claim of the token.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 18 Dec 2018 16:06:18 +0100

We don’t issue expires_in for two reasons

1) we have variable length access tokens who’s lifetime can be
extended through activity and we find clients misinterpret expires_in
to be absolute (or have no practical means of finding out when it
updates)

2) we find it actually makes things worse - with proactive knowledge
of when a token expires, aggressive clients tend to keep it alive or
proactively refresh the token.  As a result the intent to limit the
length of the access token actually causes it to be extended in
practice.

> On Dec 18, 2018, at 4:17 AM, Ludwig Seitz <[email-masked]> wrote:
>
> That is my understanding as well, I would however have expected that this parameter would be aligned with the 'exp' claim of the token.
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
>