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

Jim Manico <jim@manicode.com> Tue, 06 October 2020 21:31 UTC

Return-Path: <jim@manicode.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 183A13A14FC for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 14:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode.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 mQtn7whcbo5O for <oauth@ietfa.amsl.com>; Tue, 6 Oct 2020 14:31:19 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 3FD6F3A14F9 for <oauth@ietf.org>; Tue, 6 Oct 2020 14:31:18 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id s19so1874120plp.3 for <oauth@ietf.org>; Tue, 06 Oct 2020 14:31:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; 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; d=1e100.net; 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 smtp.googlemail.com with ESMTPSA id l188sm111126pfl.200.2020.10.06.14.31.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Oct 2020 14:31:16 -0700 (PDT)
To: vittorio.bertocci@auth0.com, 'Nicolas Mora' <nicolas@babelouest.org>
Cc: oauth@ietf.org
References: <a5b45629-c770-2294-4277-73801fff1857@babelouest.org> <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com>
From: Jim Manico <jim@manicode.com>
Message-ID: <27c3c22e-7e37-2be0-49e2-7acf96ac7612@manicode.com>
Date: Tue, 6 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$@auth0.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QKr8-gYT5XzISbm7hKCgcJfvmxE>
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: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, vittorio.bertocci@auth0.com 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
>
-- 
Jim Manico
Manicode Security
https://www.manicode.com