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

vittorio.bertocci@auth0.com Tue, 06 October 2020 21:38 UTC

Return-Path: <vittorio.bertocci@auth0.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 F342E3A14FD for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 14:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=auth0.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 h68l-N1kA8aN for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 14:38:37 -0700 (PDT)
Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 E925E3A14FC for <oauth@ietf.org>; Tue, 6 Oct 2020 14:38:36 -0700 (PDT)
Received: by mail-pg1-x541.google.com with SMTP id g29so73373pgl.2 for <oauth@ietf.org>; Tue, 06 Oct 2020 14:38:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=nfgc8FYSOt1GqNZkJK766O1MulgHPbzlWZyTqoOHsnA=; b=RTBjXJE+Pj8JtODIFAJS6saa83EtLx9WaxpQzPXM13xWgkHMXV7roAv/H3WLZVLsO3 HebmarBeMhb8XoTpDMHnA/e6MSgakvLb6QKcd99eSoMTUb87VwJZs0X7VEZR2DQaYkT9 DjnfZA52Kyse0Bqko1XQKO8+hxw9Tvgt1kfeC/iI5GCpQwaBfC7ssTxduGJjeu17juu4 B/Zx/XRpr7BuLMU5yHaDm9idoykrcRCItT720n3+Ljj9sa8Cn+qBmYlR8VJVjySB8/AZ kinCPEFMOpK4GbmSkbsQGPsRftd96uNX2SA9Y99TAU0Z/9e2SJp8nc9DtFWMTYPlVZwS MsMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=nfgc8FYSOt1GqNZkJK766O1MulgHPbzlWZyTqoOHsnA=; b=sByDIHZn21FEPDb1AGus69nulycSVbnkG9If47Q5tez2ROYGbppViKvhRz6vLR31ST oRqBqYZ183+eyhopicTWX2i5BxYRENPj3ItCLOmvv+WMtutBpDrBw1KRctv6gDW/VVhl o0Y70rGKS5dvhYuzZIi/kqQf/pbcPCW4DHDgOhzEGhH6FVk1YoC4MS0aFFk6Bepq9G2q F+w/PZArStALV8gLneVVgqWCZLuZKaXyIUZ9Vx7zTlU6ZvA6FRqXarbUOobgo+B19cvH i8NcntCsGB4iIQcxl+oGTkFzDOvbIAUnRwEorENOj/hXVvAlNXBfokr1Y+OLI1IFoHSf uDyA==
X-Gm-Message-State: AOAM530lHpy4ciYeRZwC9sI3SJyOxmrUEJOiIkf/dfTGq9bhF3VcxFyX qQYbx5TNGTFq2LeqPqCvewOoVg==
X-Google-Smtp-Source: ABdhPJy9Ednx8QInssZHKjcmxtin7lwbipT5faoyVjEvTL4gOAsIRkD87A8YL0VNqctavCImIthqAw==
X-Received: by 2002:a63:151f:: with SMTP id v31mr194210pgl.126.1602020316187; Tue, 06 Oct 2020 14:38:36 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id s8sm3603601pjn.10.2020.10.06.14.38.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 14:38:35 -0700 (PDT)
From: <vittorio.bertocci@auth0.com>
To: "'Thomas Broyer'" <t.broyer@gmail.com>, "'Nicolas Mora'" <nicolas@babelouest.org>
Cc: <oauth@ietf.org>
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> <CAEayHENkgO=K82Kyg16-nxRvj0z7=p4pDi8pJDdkd=VWXXJjDA@mail.gmail.com>
In-Reply-To: <CAEayHENkgO=K82Kyg16-nxRvj0z7=p4pDi8pJDdkd=VWXXJjDA@mail.gmail.com>
Date: Tue, 6 Oct 2020 14:38:35 -0700
Message-ID: <063001d69c29$0c0f2680$242d7380$@auth0.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0631_01D69BEE.5FB2BF80"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGLG11BRlKJ0/lyYnR+Vsd4foOMaQJgjnz4AyDBJF8CDqy+TwJpvUdiqdJGVJA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4jvsWFwsZCYRxJbw2SQTH8VNY7U>
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 21:38:39 -0000

Thanks for bringing the revocation topic up. In brief:

 

*	I agree on the comments that differentiate between userinfo and introspection- userinfo doesn’t really play a role in validation hence I’d keep it out of the JWT AT doc.
*	I agree that the introspection endpoint shouldn’t do anything special or different for JWT ATs

 

The last point is more involved. 
I think that using introduction just for checking revocation would be overkill and wasteful, no point sending the entire token if it has been already validated (bandwidth) and no point for the AS to repeat checks already done by the RS, especially at large scale and for chatty solutions.
One of the reasons for making `JTI` mandatory in the profile is to provide a mechanism for handling AT revocation easier. There is no standard today for doing that. 
In some 1:1 conversations on the topic, one solution that sounds promising is for the AS to publish a list per each resource/client including all the revoked JTIs. The RS is free to fetch that list at any time and incorporate local revocation checks at whatever frequency it wants. 
The naïve alternative is to have an endpoint on the AS the RS can use to inquire on whether a given JTI has been revoked. That is less wasteful than doing a full introspection, but still network hungry.
Both alternatives have implications on the AS, now saddled with tracking possibly large numbers of tokens. There are heuristics to handle that (eg have identifiers for sessions and use those to manage revocations, rather than trating every AT as independent) and ultimately it would not be in the purview of the protocol to worry about that, but something to consider when implementing.

 

Would it be useful to produce normative guidance on one of the approaches above? If yes, where would that live? I am not sure the JWT AT profile is the right place, perhaps an addendum to the current revocation specs?

 

 

From: OAuth <oauth-bounces@ietf.org> On Behalf Of Thomas Broyer
Sent: Tuesday, October 6, 2020 5:17 AM
To: Nicolas Mora <nicolas@babelouest.org>
Cc: <oauth@ietf.org> <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

 

 

 

On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora <nicolas@babelouest.org <mailto: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/>