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

Nicolas Mora <nicolas@babelouest.org> Sat, 03 October 2020 17:18 UTC

Return-Path: <nicolas@babelouest.org>
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 A23273A0BA6 for <oauth@ietfa.amsl.com>; Sat, 3 Oct 2020 10:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Level:
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 DPrvbBA1kzOA for <oauth@ietfa.amsl.com>; Sat, 3 Oct 2020 10:18:14 -0700 (PDT)
Received: from mail.babelouest.org (perceval.babelouest.org [5.135.181.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E13C3A0B93 for <oauth@ietf.org>; Sat, 3 Oct 2020 10:18:13 -0700 (PDT)
Received: from [192.168.1.50] (bras-base-qubcpq0634w-grc-02-69-159-172-90.dsl.bell.ca [69.159.172.90]) by mail.babelouest.org (Postfix) with ESMTPSA id 3FDB32034C for <oauth@ietf.org>; Sat, 3 Oct 2020 13:18:10 -0400 (EDT)
To: oauth@ietf.org
References: <CALkShcsApoXc=4p_e5mbs9vQCDPHDLrdt-8bd5D_5XhLGYOOJA@mail.gmail.com>
From: Nicolas Mora <nicolas@babelouest.org>
Autocrypt: addr=nicolas@babelouest.org; keydata= mQINBFmJqr8BEADBhkCFzusIdcIn8V8+Maee1V+GhD/sNS/GuqDL5WwVlrdv6TDrEiiIGvX7 6fs+F1/wP9z/8P2QVm6pxZG+MGpARmWyYkMyklMpqjuXN8JMutjAM9ymouEtVcb3CV20AgXU 7Qe1M2Dofmg4waRM5vHsLI0gvARgo5Rxxc+DoKS8GApE2nbXB8imFLJ48L1FnDVbQWpIW+mz O7dtMY6XQkpvqtRkYrEfxvVDHD06fG4SIzVF8QL1iiRHncG+5u24AU1FxKxxFNYUTcQxCQZ5 JNHsANmgsWCcheEL15B0eDYrJ7jDPaGiN2Ullh4csO9zlYyfWA84I4CGi3En5C69M7uvOxvy g7LL9GsrAaH51ksR1ksDH41OMSBVkeLSpU8RPudy8bpIsGXNtqpAOFjhGoJz6POggY/HmAJe qRDF1HfjPFFm3dZ7E0dLR0aPvxTwuzIERRcjKrzMqslLTjgOVUXSfjhCtWPmcRbwCHWR2k/i cho20wnEVJsVrbNld/0fMvxenrWSmuwawnDHTSwK5Sy5ec2JQy6qvQ2zJIYrdg0eHur/sURi SbAyNmfoOII9GBTAFm13XkHWbBysppGQVAyowYO2h0JC+6MVxQRndBsCC4jRNiT9wptl4rOh o4GYW4d/smGlCbki/bYdSItbtk4rjHAyl+WYM6Jpy1sZXe7SDQARAQABtCVOaWNvbGFzIE1v cmEgPG5pY29sYXNAYmFiZWxvdWVzdC5vcmc+iQJRBBMBCAA7AhsDBQsJCAcCBhUICQoLAgQW AgMBAh4BAheAFiEEhAWwL8wo75dEyPJT/oITlEC9IrkFAl8FCPUCGQEACgkQ/oITlEC9Irkb ZxAAodrP5pSZFAbxqu9vKtkY4xNLyV+xVmjxEd376M8chbrEmbZaKd7v2sAC+RfJzZqygTsU ACiwM65jEbM87pIUZpaC6EhqRkmciTjPDrDEfKvf6TvOPkNCVgH8pPDligkA/VhmXYW+enOx jJfBrJstKmSa19heKwB6tqbgbIJ5GIQzLbPRCW4jvZ0NBZ7p3drbz0llM5y7e+jtytrOOswD O3z4KGJMjKiQwU88SJ1HRQc9CDe4BW9AZyljWf91FUd1Ees1n8X/6HwVySf1Q6Tpa3K7RDT/ fVvA38eI/X+MLdYMJvX45YCi61ySfFf/afXGkFgwVip98qe/W9AAOCYYj0+XQajgjfExnBAB /6Qvs1kVrT1Sg1LElyMZtk9nZQxOv2MqMQghgeptgvjILa2knYJKYPO1LHGVAXZc1CxB2tgt MrxdaGAw6ObW+d1Lt1ohVd78JHm23MhBnly8LjEJp+gIWB9zqSlkgGocWP9Fljf9K2haAieQ Ot/C3/9NohYzn15v1Ib/iEAVzV7fhD7V0nhTZFuLPlxuRWc4QY3E3j8irRcdxjjcnG1PxMOh KJH/R4xILS+iEsot8cNr6V63H1vVMcKF34EFmWTw2cS13FKrl13klcHD0eoOXpNCte2jwxrz 26edRd+nC8DBUG6OCdroOzEsvkI4IcJZgfbzooG5Ag0EWYmqvwEQAOsjmWy2MtpLohfEffsZ a988t2MvJMUrmQmrJmSEY0xYebCZFTcFWvPQzRO9r9rdnUH59ckbMp69CEowGyuliGRsqRsy Du+t6JaFmNDLLme9soDhoyFnVySZhYTE6TZCJSlMOgsME3tURkb4VX0fDllV4fWTkudsjHHE gZ3MrWbFwIGAmh2/MeynVJl59UgoEosf7L6xwBkNucN9JSj/Wk+Cu6iCySmDrteu0M/+ZnGB /sYHTCWtCusm314G4IPk1ciO2Xwq8Qg8pPECVh/8a7xkK67RzAcuX/v1ZQfrBPflcHICwEy2 4bx0cOJ2PnT9eSk/YvoYTnYphM2hBW/legAjOm7BcPFxMwvQmMTUQoB9EV7K66Iydxf12C1F 0kYyA3/gdjMiJK9ayNiSBVQWuH9mUQ1sToOHLg0uoMQFBvlEwhas7tVVoAqixHKxjvYbdnUW ZLabZ08CU00sYcRKVwunefCc0UWd5CJ/gp/Vl0UxkkLLwPqf5Nu5mZjx4wLrbg63mHXxqfTI FYUTwT9dTjJBHqxq+GGKdjVhzgQqNw2I/hxOumGHhwTteAyK1f7TJzUP2zu6a6IF2rD1UCzI DbQ18tkIzGJ6IZhyB1rVY8DlXuNBzebwb4InKDvrZNvdfI8YE/LhMN+CGnDVGph/zBgCLx7v jAodyT+4A/pHWVzvABEBAAGJAh8EGAEIAAkFAlmJqr8CGwwACgkQ/oITlEC9IrljgA/9FvQX aWYHq4O7roGEJhftnaFye3j8tkrWFhvp9E7eadbxcKWe1g4ZsqgAYBANLc+sjHYQmRSvkWJY ymed5A9zB824vtWVKqVwV/A36SSNNywiOvDcoyAY1uONDzeMJTOJ3JDh6DXwAoprFvQ2sDxQ 1FO+0rSjNJOHGfMtnbSe7+ZT00mFwxXHZDMgRSIkrlqDe5eWL+vnYguV7lar0s/GM8SyXSga Wo0wZwJkuvbS0debRcutJUR6dYovyGNoS50811wowsFZWynRUhL92LV+xCDCG4n0L5/CG2po awvkOwoNiGtSjWIqLhq9fR/wh3N6dBIoWygl/636Qcibn9l1nyMw3TzVHOci/PynwHFY7NuD 4FkIKQ4iwLHKmZT1aAwwneFeBFrY4iFBlDcCcFz9Tzje5T/sdVEyF3h5/OM3D+/WOgN3goQk QedL+NP+z2PETKKQ61Bb2i0kEuBmmgQb71EUIo+7hNXxEH2RkIc4zmXBLCrsIjDBWW0XWkxG iSbpfuXJyVniIIS19kAzpm6839+HUZsgnF+36EhaoM+Ib1s+2hdkwCtSLXMJpKYV3Ntr/Xn4 /4HcTJpp1iJKNWf1YGF7qzLFnxZijR6G8kR7jYEsZwZFxCX6XYm3nsPcU8NhgkRSSXvawaGE puuDhgFV8Kha5yEPTBe9H0BFe0srkfg=
Message-ID: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org>
Date: Sat, 3 Oct 2020 13:18:08 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CALkShcsApoXc=4p_e5mbs9vQCDPHDLrdt-8bd5D_5XhLGYOOJA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vYzf6b-6sm8yxxv355b6oz9IAcM>
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: Sat, 03 Oct 2020 17:18:17 -0000

My 2 cents,

Le 20-10-02 à 18 h 19, Andrii Deinega a écrit :
> 
> Here is what I would like to get a better understanding of:
> 1. How should a response of the introspection endpoint look like if the
> RS makes an attempt to introspect a JWT access token?

AFAIK, the RFC doesn't specify if the introspection should be different
between an opaque AT and a JWT AT, so my guess is the introspection
result shouldn't be different either.

> 2. How should a response of the OpenID Connect userinfo endpoint look
> like for a JWT access token?
>There should be no difference in userinfo response between an opaque AT
and a JWT AT.

The userinfo and the introspection endpoints have different goals, and I
don't expect the userinfo to return data based on the AT provided
(except to identify the sub it relates to). Instead, the userinfo must
return user claims based on the AS configuration and the claims requested.

> I assume that it’s expected to have no difference compared to a regular
> bearer token (given that a particular implementation of the AS provides
> these endpoints). Does it sound right?
> 
That's my opinion too, although I don't recall any specification talking
about it, so I guess it's a matter of implementation.

> If so, what are we going to get if the RS or the client revokes a valid
> JWT access token using the revocation endpoint (RFC 7009)?
> 
> Do you think there is a need to add more detailed information about
> these scenarios in the document? This way, we could refer back to these
> sections in the documentation in case any disputes around
> security-related topics come up.
> 
If a client revokes a valid AT, after that, the AS introspection should
answer an error response: https://tools.ietf.org/html/rfc7662#section-2.3

The problem here might be: how should the RS know if a JWT token has
been revoked on the AS?
I don't think there is a specified solution for this because it all
depends on the implementation.

The RS might use the introspection endpoint to check if a valid JWT AT
has been revoked or not.
- If the introspection endpoint is checked on some JWT AT use, it might
lead to an attack
- If the introspection endpoint is checked on every JWT AT use, then the
advantage of using a JWT AT is close to 0

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 the client uses a proof of possession process, the revocation
endpoint may be useless, because if the client doesn't want an AT to be
used after a certain point, it just has not to use it anymore.

/Nicolas