Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 08 October 2020 10:21 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 482B13A0A1C for <oauth@ietfa.amsl.com>; Thu, 8 Oct 2020 03:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (2048-bit key) header.d=lodderstedt.net
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 9NVc5hyFXphb for <oauth@ietfa.amsl.com>; Thu, 8 Oct 2020 03:21:30 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 EA4203A0138 for <oauth@ietf.org>; Thu, 8 Oct 2020 03:21:29 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id t21so5254129eds.6 for <oauth@ietf.org>; Thu, 08 Oct 2020 03:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IxX3lT5a8wUGNNfGSMC3YukBZMEeQI4WeXAkZh4mczo=; b=vT2ODjZzx1gZ784MmCB+1whSA1OvJOQ1OMfBp2bFl6iqT4PnI56aPhDVR6cO7LXnU2 jHyzs2fkfwzuyDSjwAgsB5wJRky2TZtEYiXsNfezCxoLkX64HkEAODWz5KN3iuTFAAXz SPruGkvJVkjYbCtExPcC25OqXeJs5h7AUXzkN9f8tTIaT8uFmi32szmvb1AWXkFox81O 4fmYVvBsF/svUHsYiUzuA2MN/06FMM7/iHP3zeh8Kw5z20VzduHZQdaQUxoiM31IUkHM /yDn5vpV7YeJLeBLyHoFd6NWRwod5a/H0w7bMt03ZSCCDBt6insvZMlOAsLwH2B2L0qx sHdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IxX3lT5a8wUGNNfGSMC3YukBZMEeQI4WeXAkZh4mczo=; b=mmlS2mn+Q0Gu/qKkZp6wE8sfv782QZGriJd9fTSRNXq+U0eqJGCrbIRh7nEQ+TJcq2 hts1GSt7JvbUQKeBviv+fPqrjIRHDZWKJzhPng71iPDU9aiqOEHbLgmRQOaQXREr11n2 yYt+/KQXLHZM10NoMrllYQ9aWqaFsVTb542hr19m8wtD+kmp2hMrfOfnnAjmWc6i/2hP QM1A+gjgBM2ABRthfJVmvCs4y6/uveNE1vVBHzvIMNT+Fl2/6hzS7xSdUxMWbqmSPhiI KVUmuBQlU4/qYhPhbJWO9kcMRzkq2D0RoWJIRsZgjqN4rbRysL0YC4foHt4UNq1PQ+hK SwqQ==
X-Gm-Message-State: AOAM530yiiXDYxiSvmm9GZg8Ulkyx3gWbCD6pGy7von257X4+b8nyIjL GrqY7nH00tYuLlHBweTJ47i1iGzq4MEBGGSe
X-Google-Smtp-Source: ABdhPJw+ZznssLRQQfO79P588GVrxoEdCCjj7LCooxpzvH9CThKWWF3AcgG/xZ2mdaNx7g06lxDoVA==
X-Received: by 2002:a05:6402:c84:: with SMTP id cm4mr8163480edb.270.1602152488140; Thu, 08 Oct 2020 03:21:28 -0700 (PDT)
Received: from p200300eb8f1e2a7aa8a05874361f4c54.dip0.t-ipconnect.de (p200300eb8f1e2a7aa8a05874361f4c54.dip0.t-ipconnect.de. [2003:eb:8f1e:2a7a:a8a0:5874:361f:4c54]) by smtp.gmail.com with ESMTPSA id f28sm3682521edc.94.2020.10.08.03.21.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Oct 2020 03:21:27 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <CAPLh0AMfM5tAm4P+TmXHTDuB+2D1W89aDmTLTR2iTU1+b7b-Qw@mail.gmail.com>
Date: Thu, 8 Oct 2020 12:21:26 +0200
Cc: vittorio.bertocci=40auth0.com@dmarc.ietf.org, oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DE046033-9633-44AF-9169-7F0F3CD9D28D@lodderstedt.net>
References: <a5b45629-c770-2294-4277-73801fff1857@babelouest.org> <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> <CALkShct4=DPHygj5ECSuDo09xA4H73SDnjXycbZi3L+ktjZDVA@mail.gmail.com> <064801d69c2b$229141c0$67b3c540$@auth0.com> <CAPLh0AMfM5tAm4P+TmXHTDuB+2D1W89aDmTLTR2iTU1+b7b-Qw@mail.gmail.com>
To: =?utf-8?Q?Se=C3=A1n_Kelleher?= <sean@trustap.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/51kKSeLo5lREKQRB-4OVHnZLd7w>
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
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: Thu, 08 Oct 2020 10:21:32 -0000


> On 7. Oct 2020, at 19:45, Seán Kelleher <sean@trustap.com> wrote:
> 
> Hi all,
> 
> Long time lurker, first time poster, glad to be finally getting involved!
> 
> In terms of weighing in on the revocation practice, I don't think this document needs to address it as JWT ATs don't seem to require special handling in this case. I think a general coverage of approaches to token revocation would be more appropriate in a BCP.
> 
> One thing I'm unsure of when reading this is how a RS can depend on an AS to give it a JWT AT. Due to the opaque nature of ATs, it seems natural that an AS can change the AT profile it uses at its own discretion, but there's no negotiation or parameter that can force an AS to return a JWT AT, with the potential for breakages. Do the RS and AS agree on the profile ahead of time?  

yes, they do. Basically, the AS is acting on behalf of the RS and centralises the authorization work. 

> Perhaps this is specified in a separate document, but I think the topic of profile negotiation should be covered in this document, even at a high level, or reference to more detailed coverage.

Good point. I think this is a general assumption in OAuth. Should probably go into OAuth 2.1.

> 
> A few other notes on the document itself:
> 	• Section 2.1: Is there precedence of "application/at+jwt" being used in the wild that prevents the SHOULD from being a MUST?
> 	• Figure 1: Nitpick: An `&` that looks like it should prefix `state` is on the preceding line.
> 	• Figure 2: The example `typ` is `at+JWT`, should this be `at+jwt`?
> 	• Section 4: This is a personal opinion, but I'd recommend moving the step concerning `aud` validation to the top of the list, for focus. This is because, having personally taken more than a little while to figure out the difference between access tokens and ID tokens, I see the risk of cross-JWT confusion as very relevant. I think the necessity of the other steps are a bit more obvious.
> Thanks!
> 
> Kind regards,
> 
> Seán.
> 
> On Tue, 6 Oct 2020 at 22:53, <vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote:
> Hi Andrii,
> 
> Thanks for the thoughtful comments! Here’s my 2 c.
> 
>  
> 
> On the proposed language: given that the JWT AT profile is just providing more details on the content of an AT, making JWT ATs a proper subset of all ATs, readers should have no reason to believe that introspection or any other existing spec discussing AT behavior should operate differently. That assumption holds for everything across the board, hence it would be a bit odd to call out this particular case. On the userinfo case, I would find it even more left field to say anything about it.
> If we do reach a consensus on specific revocation practices that apply to JWT ATs specifically, and we conclude that they should live in this document, I will be happy to add language accordingly.
> 
>  
> 
> On the AJWT: I hear you on the dissonance that JWT AT carries, but I am very hesitant to introduce new acronyms to an already crowded/impenetrable domain.
> JWT access token might not roll off the tongue, but at this point ‘JWT’ is nearly a proprietary eponym and the expression “JWT token” is extraordinarily common in literature, a quick google query will give you the full measure of the phenomenon, hence I think we’ll be OK with the current form.
> 
> Cheers,
> 
> V.
> 
>  
> 
> From: Andrii Deinega <andrii.deinega@gmail.com> 
> Sent: Tuesday, October 6, 2020 2:25 PM
> To: vittorio.bertocci@auth0.com; oauth@ietf.org
> Cc: Jim Manico <jim@manicode.com>om>; Nicolas Mora <nicolas@babelouest.org>
> Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
> 
>  
> 
> Vittorio and WG,
> 
>  
> 
> Would it be possible to include something like the following to https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10
> 
> 
> In case the authorization server exposes the introspection, revocation, and OpenID Connect userinfo endpoints they MUST act in the same way as it happens with a regular access token. That allows the AS to change the type of an access token on the fly and that won’t lead to interoperate issues. Plus, the consumers of these endpoints use them regardless of the type of access token.
> 
>  
> 
> The way how the AS can notify RSs that the token revocation event happened (if it decides to do so) is completely left to implementers.
> 
>  
> 
> ?
> 
>  
> 
> Another minor editorial thing from me is it would possible to change and refer to "JWT access tokens" as AJWT. Thus, this document won't repeat the token word twice.
> 
>  
> 
> Regards,
> 
> Andrii
> 
>  
> 
> On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=40auth0.com@dmarc.ietf.org> wrote:
> 
> Hey Jim, regarding
> > Every logout event should trigger token revocation
> That isn’t necessarily the case. An access token represents the ability of a client to access a given resource; the fact that it requires an authentication transaction/session establishment to be issued to the client does not mean that the AT lifetime is tied to the lifetime of that session. Say that I allow LinkedIn to tweet on my behalf. Once I have done that, it doesn’t matter whether I stay logged in their web app or otherwise. Even if I log out of the session in which context I got my twitter AT, I can still post on LinkedIn from my native LinkedIn app and the corresponding post will show up on twitter as well.
> Now, one might choose to *explicitly* tie tokens lifetime to originating sessions lifetime, see the discussion on the OpenID Connect group about a possible online_access scope for influencing RTs and Ats (in particular, in the context of SPAs) but that's additional semantic that isn’t defined today.
> 
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Jim Manico
> Sent: Sunday, October 4, 2020 5:17 PM
> To: Nicolas Mora <nicolas@babelouest.org>
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
> 
> > In this model, considering that token revocations don't happen a lot...
> 
> Just a brief note, a secure piece of software makes the logout feature prominent. Every logout event should trigger token revocation.
> 
> I’m mentioning this because a lot of OAuth solutions in the mobile space literally ignore the logout event, such as Facebook’s mobile OAuth solution. 
> 
> - Jim
> 
> > On Oct 4, 2020, at 6:55 AM, Nicolas Mora <nicolas@babelouest.org> wrote:
> > 
> > Hello,
> > 
> >> Le 20-10-04 à 11 h 27, Thomas Broyer a écrit :
> >> 
> >>    There might be some kind of pushed events between the AS and the RS when
> >>    a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all.
> >>    Like this, the RS knows if a JWT AT has been revoked or not.
> >> 
> >> 
> >> If there are some kind of pushed events between the AS and the RS, 
> >> then it could push the revoked (and/or expired) opaque AT too, giving 
> >> almost no advantage to JWT ATs.
> >> 
> > Not necessarily, let's say the AS informs the RS only of the revoked 
> > ATs, when a RS checks an AT, it verifies the signature first, then the 
> > claims, then checks if the AT has been revoked by checking its 
> > internal list filled by the AS pushed events.
> > 
> > In this model, considering that token revocations don't happen a lot, 
> > the ratio revoked AT/valid AT is very low, so the advantage of a JWT 
> > is important, because it means not so much communication between the 
> > AS and the RSs, and a very reliable AT.
> > 
> > But this means a communication mechanism that isn't standardized yet.
> > 
> > /Nicolas
> > 
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth