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

Jim Manico <> Tue, 06 October 2020 21:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 183A13A14FC for <>; Tue, 6 Oct 2020 14:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 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, NICE_REPLY_A=-0.213, 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 mQtn7whcbo5O for <>; Tue, 6 Oct 2020 14:31:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FD6F3A14F9 for <>; Tue, 6 Oct 2020 14:31:18 -0700 (PDT)
Received: by with SMTP id s19so1874120plp.3 for <>; Tue, 06 Oct 2020 14:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=to:cc:references:from:subject:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=pMZqCH42N1F6oyRMT47m4NXNLlhTfJQGd+/jcg4HFdY=; b=OQOiI01raadR8scxbjPSvLvrvznkViI4Mzc3CUQWv13kYXEASdCp1UJ4Yl2fw5Js4u /k0DzRLP8WllxMeIqTvVTWGua0LcSSmE20tTAhWEuD+ZyNihHq9K0KFCk2r/aLWpDCWY 22uE5c4MpCdzRchlhywCjnWDkg0GMEMGiz9Kp6PYi+U+oKlr1PfTYVdnACvGGVDa7e6W IxPu/axDxSxrvbWfd6jJWdr45OZ8dMnzp9+3MHOprwlYO1mH729WygawfXKTuyv3buVm H61yzspo9b2fkgqs0vXR4GYp4H/ckytzyLeFbtxxPCXtQdV8u5XHlpqw5s5UxhJlh+cy DPoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pMZqCH42N1F6oyRMT47m4NXNLlhTfJQGd+/jcg4HFdY=; b=tqkfRbIo/t5BFuStSkIVFHsISynXgMWY3SyMhJ+8NxaAndpa8waBYIqctCOMz9Nmv9 EhCNCjTL4M407BwoaqfFa+/9nLB0RnSKEt2NXxYnSTVxzY3/a86M6E/o68J0FSUhloed XsKdAK2/KcgYsxiVxuMeMA+Tf36mA7wLFfUbzKdNksHfn63D0RV67J4B0D8d5zE9xNs+ AJXejcXxQUlarRZ19iJxRzqeDSPCfoQu4/n5CRowR/wFyDF/gj+f/ldbEgqbCWtIz5FA 76ZWlW/iB5iLMTT5IoFtLbk5AuTcbg/XK9uM0aACjqVVCOhkXInIX/v+WG3HFl2OfUiy lCbg==
X-Gm-Message-State: AOAM531RDMQNGdDlBfewwG2ywabUk0RveVC1YbV9fxikoKOpa5cLaxu8 ANfZE+NIZxiwr80E2PBwabW4tXr1Jl9VGQ==
X-Google-Smtp-Source: ABdhPJwQu+1D206MfdPeFLsR8b3E6zGROWMQAk+zBH7TEEx0BvzncZm6LEWUZ6340JPqbjSWZDsL9g==
X-Received: by 2002:a17:90a:c501:: with SMTP id k1mr94908pjt.170.1602019877524; Tue, 06 Oct 2020 14:31:17 -0700 (PDT)
Received: from ?IPv6:2605:e000:112c:15:cdbe:66c2:9fea:a3aa? ([2605:e000:112c:15:cdbe:66c2:9fea:a3aa]) by with ESMTPSA id l188sm111126pfl.200.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 14:31:16 -0700 (PDT)
To:, 'Nicolas Mora' <>
References: <> <> <060901d69c26$ba2deab0$2e89c010$>
From: Jim Manico <>
Message-ID: <>
Date: Tue, 06 Oct 2020 11:31:15 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <060901d69c26$ba2deab0$2e89c010$>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
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:31:21 -0000

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