Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
Thomas Broyer <t.broyer@gmail.com> Tue, 06 October 2020 12:17 UTC
Return-Path: <t.broyer@gmail.com>
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 499EC3A1449 for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 05:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 s44NCTL_hPZJ for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 05:17:05 -0700 (PDT)
Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 678573A1448 for <oauth@ietf.org>; Tue, 6 Oct 2020 05:17:05 -0700 (PDT)
Received: by mail-yb1-xb41.google.com with SMTP id n142so5616821ybf.7 for <oauth@ietf.org>; Tue, 06 Oct 2020 05:17:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bRUSJY3j2SsooMoIDs14IOynOO15tKoQ4oVDiTjKTlk=; b=hqU+BzHM5JQlPQj2Jj6L2J1w8s122GEsEvMvpO0+MxxodAGb6jTfmb0+O9ZVdatsZ9 hsqPFfrV9AORrJDXDJbfoejT1Pi1+L27NiWUIB3zrnZs6+/qObNbOCyc7aAjDFQeWvxZ XAL8mca3l/P5fwYCfMU7MoboKiVUo5WD7ziCAsafeAVYreDrYktmhkQthxbPNAJjov44 QrL5/dm63rfgdd/Z5FUygy798k5LEgpyQP9nz8Cc+0V71YVNUm6kSluLer0n5Tp0R+AL qRXbdhJBupP1w2lhtg4eTMVla9aLilBmhEru20M8LrU/3W73uhxriOYESV4NYEg+1oau +s9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bRUSJY3j2SsooMoIDs14IOynOO15tKoQ4oVDiTjKTlk=; b=QWIq2yRhnPFUp2UXWxse63QnYfGD86TcXex674+fIY2YBe6TD7HwiPHwhtNg+S9FC9 3A1kXtaBX/4uzcmm9T/m2CZQMORmsaHk+ktk7XGwsAmfD50nswo1qzr6AFIU/CbtYaCa nSBifAovVsiggdH3awQbgGjvklYxUsHZMmQBeQgvq0f7lFQbMbfLYN+QchqrcUtNCz2U /F84AATNK5XtAeE2oVm+d3JizGNKj+jg1EF/yNL6GPd+O0RrP9hfsJuBR2AnjgyaiHiH 84iurTPXvOdkB4c66Q3KaSy9XObe48B01sQLhROKCSBMGF6GetQsQ2AOcSqnk/B6PRqx /czg==
X-Gm-Message-State: AOAM533/XYhnZ1aNwyaoRXBI/VHM1ZDgUZCpIkCa0CaEZu2QdD5Oj2oF B2FZ6He4LpIOAb4Fmo7uWKe6XijKewBYTbzAiz/+cP/M9kI=
X-Google-Smtp-Source: ABdhPJyyT51b+xUlwhjqm1/apBYT+6mE+PdYYTMnnlDa3iWFR2lIT2uMpcG2+Uki2/XUYpnamKSzZtAhKtuHaIF7BlM=
X-Received: by 2002:a25:7314:: with SMTP id o20mr5771464ybc.211.1601986624268; Tue, 06 Oct 2020 05:17:04 -0700 (PDT)
MIME-Version: 1.0
References: <CALkShcsApoXc=4p_e5mbs9vQCDPHDLrdt-8bd5D_5XhLGYOOJA@mail.gmail.com> <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org> <CAEayHENEcr21QHNF9ATupiRwbwBNJfi2kEryGR8A2=UL2JUckQ@mail.gmail.com> <a5b45629-c770-2294-4277-73801fff1857@babelouest.org>
In-Reply-To: <a5b45629-c770-2294-4277-73801fff1857@babelouest.org>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Tue, 06 Oct 2020 14:16:53 +0200
Message-ID: <CAEayHENkgO=K82Kyg16-nxRvj0z7=p4pDi8pJDdkd=VWXXJjDA@mail.gmail.com>
To: Nicolas Mora <nicolas@babelouest.org>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000acaeed05b0ff9314"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kPtgJKferD0yoam2jgCOeIYJWV4>
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: Tue, 06 Oct 2020 12:17:07 -0000
On Sun, Oct 4, 2020 at 6:55 PM 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. > Well, you were the one saying that “the advantage of using a JWT AT is close to 0” 😉 (and I was the one bringing the advantage of being able to do some verifications prior to contacting the introspection endpoint, btw) In any case, for an opaque AT, you only get to introspect it once to know its expiration (and you can cache the result); so those preliminary checks you can do with a JWT only save you one introspection request IFF the token is not valid, e.g. expired; if it's valid or has been revoked, then you'll have to introspect it anyway. And if you imagine that "pushed events" mechanism, then it would work the same for an opaque AT or a JWT AT, saving you the introspection requests that would otherwise be mandatory for checking revocation. So (and I know it wasn't the original subject of the discussion), a JWT AT can save you, compared to an opaque AT: * a call to the userinfo endpoint if it embeds the claims you need * a call to the introspection endpoint if it's expired or otherwise invalid, and/or some memory/storage space that you could use as a cache for that information for an opaque AT (to avoid issuing other introspection requests, as an optimization / compromise) -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
- [OAUTH-WG] JWT access tokens and the revocation e… Andrii Deinega
- Re: [OAUTH-WG] JWT access tokens and the revocati… Nicolas Mora
- Re: [OAUTH-WG] JWT access tokens and the revocati… Thomas Broyer
- Re: [OAUTH-WG] JWT access tokens and the revocati… Nicolas Mora
- Re: [OAUTH-WG] JWT access tokens and the revocati… Jim Manico
- Re: [OAUTH-WG] JWT access tokens and the revocati… Thomas Broyer
- Re: [OAUTH-WG] JWT access tokens and the revocati… vittorio.bertocci
- Re: [OAUTH-WG] JWT access tokens and the revocati… Andrii Deinega
- Re: [OAUTH-WG] JWT access tokens and the revocati… Jim Manico
- Re: [OAUTH-WG] JWT access tokens and the revocati… vittorio.bertocci
- Re: [OAUTH-WG] JWT access tokens and the revocati… vittorio.bertocci
- Re: [OAUTH-WG] JWT access tokens and the revocati… vittorio.bertocci
- Re: [OAUTH-WG] JWT access tokens and the revocati… Seán Kelleher
- Re: [OAUTH-WG] JWT access tokens and the revocati… Torsten Lodderstedt