Re: [OAUTH-WG] JWT access tokens and the revocation endpoint Tue, 06 October 2020 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1709A3A1501 for <>; Tue, 6 Oct 2020 14:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yWEeicPX5Wlf for <>; Tue, 6 Oct 2020 14:42:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 537FA3A1500 for <>; Tue, 6 Oct 2020 14:42:05 -0700 (PDT)
Received: by with SMTP id q123so126164pfb.0 for <>; Tue, 06 Oct 2020 14:42:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=vbBmspJT+cWpoG7atuEOCPDTiiDA34ZsyLT/v1tdbI0=; b=ABB/kJQq9mJ5Uk7c5jjlwM42lZS3sYG6mv963UsC+uiQXjm51OPmRVkC913s27C6wo Gpv4OsdkBfCpl6Twt6ImftZgaZhYgqJLzYIa+aXzINIatxp81/9Ie6eCco89PojUMTTP Igqpv7xWMjVF5p2yRjvhfv3EnX0gZbiHSZmd99dc0/+I7WRY/tKtkECFCu+55AZ7Ko4r sAJSmiOo44aBPgbN2YdqKUuCt1qsxGMouOsvu7Sm8GXveW4j13tJGbwZVMSDGCFpqKnQ Y7UIMfQFsDqPXxPWsTk0UVxMV6r4qt4wkJs99AAcGQydyGCSmX/PYyLq7rN6+lHEdR9+ fwZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=vbBmspJT+cWpoG7atuEOCPDTiiDA34ZsyLT/v1tdbI0=; b=hQHUTJmzUXqR9JXt6l5mTVACg5k6AWK2GSWK7P13nfPqbUwvm5RcbNKzqiA6BRQthT 75Wnq22xdvVGQcMH+bZbb+EDctwIaYqNSy0e1nvhkfmlmrzdffhDNi5iuZML+J4DXOjA WooxwaT/gHlNOmkOfalWcj/3hd4Du37YOM70vTRVVByj+TAa8iEVDJTaREVdrioxcm+2 d3gMGAey7cDBGA2TMlylu7Dfdqa4dl01UND+Jkx7rfLOkCVsyBARcCnf/5moBKfSdTRG b59O2MQOpQeCT2uy4k4EcZQzgTRnw+Jd0AChjlTdbhRxh2d1SaZ0WyLhEh+fUsqg1Q6I 9VVw==
X-Gm-Message-State: AOAM533nA6rPAn8PVGGthGMx+d+4rpHo8GdbNaDKBiDWy3ZWsKDzFDxo FWYald+JAGteMpOmQstNneJKnjJcamM2PZjT
X-Google-Smtp-Source: ABdhPJxY+GTSc/lhGCy9RIRO7ZCteFcJvI8g21zOmJK7GPcrs66zVhwN8F5V/uROzQydUs309huvmg==
X-Received: by 2002:a63:4811:: with SMTP id v17mr173261pga.253.1602020524751; Tue, 06 Oct 2020 14:42:04 -0700 (PDT)
Received: from vibrosurface7 ( []) by with ESMTPSA id d129sm128949pfc.161.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Oct 2020 14:42:04 -0700 (PDT)
From: <>
To: "'Jim Manico'" <>, "'Nicolas Mora'" <>
Cc: <>
References: <> <> <060901d69c26$ba2deab0$2e89c010$> <>
In-Reply-To: <>
Date: Tue, 6 Oct 2020 14:42:04 -0700
Message-ID: <063701d69c29$886411a0$992c34e0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIOrL5PoOMmS7FkPutnv0CxOSedfQJQ4VslAe3qkQ0BaqH+pKjtrYGQ
Content-Language: en-us
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint
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, 06 Oct 2020 21:42:07 -0000

Thanks for the clarification! I agree, the scenarios you described would be improved by actually killing the ability of the app to access the resources, instead on relying on the client to discard the tokens without leaking them. That's why I am a big proponent of the online_access scope, tho I know a lot of people donā€™t like it as it perpetrates the offline_access original sin šŸ˜Š

-----Original Message-----
From: Jim Manico <> 
Sent: Tuesday, October 6, 2020 2:31 PM
To:; 'Nicolas Mora' <>
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

Thanks for this message, Vittorio.

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

Ah, of course. That makes perfect sense.

I should had been a lot more specific. I was commenting more on how many mobile apps which use OAuth AuthZ refresh/access tokens from the native client RFC do not support logout. I noticed that when I log out of the Facebook mobile app, my refresh token is still active and I'm not really fully logged out. If I am in a native client triggering a logout event, I would expect to see revocation in play!

Also, in an microservice environment where JWT's are used as client side sessions, logout events often do not actually revoke currently active JWT's. #lazyLogoutBooo

That's all from me. =)

Aloha, Jim

On 10/6/20 11:21 AM, 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 <> On Behalf Of Jim Manico
> Sent: Sunday, October 4, 2020 5:17 PM
> To: Nicolas Mora <>
> Cc:
> 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 <> 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 mailing list
Jim Manico
Manicode Security