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

Thomas Broyer <t.broyer@gmail.com> Sun, 04 October 2020 15:27 UTC

Return-Path: <t.broyer@gmail.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 E48DB3A011B for <oauth@ietfa.amsl.com>; Sun, 4 Oct 2020 08:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, 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=gmail.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 f4kENM166QQG for <oauth@ietfa.amsl.com>; Sun, 4 Oct 2020 08:27:52 -0700 (PDT)
Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 09DDC3A0112 for <oauth@ietf.org>; Sun, 4 Oct 2020 08:27:51 -0700 (PDT)
Received: by mail-yb1-xb41.google.com with SMTP id k18so4881606ybh.1 for <oauth@ietf.org>; Sun, 04 Oct 2020 08:27:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B2ZVq0d3op3owBS6qlofzmfPGaRHnQlP+6P8qFYlv6o=; b=ZUbsqVXi855/9SFDPrMq/i2eA9aNfpfGmaopDZRz2wvsu/+rpFP97q6D76FFLe8zx3 f9fIvzbcitHHshbVfqb7K0RwH+c2ON5wGekPb0qCUv1cK8lBbVxIdJrxwdo5ZgwaS/cb s/hTl88bo1fvYXISX+m4UvUeTi/FI7LTTzg7FG4IXH3L1v0UjllgC9jVKpaEsV37sMzl RZZl2vugIkt0fYqSWeIrFH8NGyDO3D5Kht/yzrzPnETVmdjcXFyesFcaIiuDhNhgCaZX Ax8xK1DfUyU/kHrMCQaS5NEKpYCPnvUYd9mMfnsdR2zyz34sZ+cckENIqzOmNW7uNuh3 K6hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B2ZVq0d3op3owBS6qlofzmfPGaRHnQlP+6P8qFYlv6o=; b=RTxVUpVCgoF5Dk+ri+zBRvxdoLNyBuQh3X4DbkaVjUHyVF+J0P+FAc/TDWgl/wAWHI 3wEvQthm7C1qP4d+MHrCgBeZbFXdDR445ILR15K8YkxRNLoGBR7jU3oKZ14Nc3b+jQon 3X61tq3aQj/MyFnVIOu3BKypKLfrvfaqteS9KTx38pgnAmMAjRifPUOyqDkLCJeMIZf1 thYKURcQSIGJsmYH56BXdtSS+RcakjOH2Rf7HR2vuS8qObiWYvqHobNJ+b5v0J9YFQZK yNke2bwh9OVvXtXIKBtCZ9Uq7ygh2Jfhtny3ATsuXlIQpHPGAuJpOKQNNpQpP2u3/98M sG/Q==
X-Gm-Message-State: AOAM530jVNeHKTuanTJBNEr5DDu2z1lU7T0ZWXc1hut1+HOBhzz4HrzW 4Fb/2MkSAMgm4trSk6gZVsd9voBGkgycf4+/++6RnDeb
X-Google-Smtp-Source: ABdhPJwyC1Jw7xtV152MfLl8TKAKFXgk3LBLB3ftn26iUOdNpzISXiGVW1VVU35/yagPcbvuu1+pAJSTBSAGDcLyj28=
X-Received: by 2002:a25:3453:: with SMTP id b80mr14373753yba.237.1601825271013; Sun, 04 Oct 2020 08:27:51 -0700 (PDT)
MIME-Version: 1.0
References: <CALkShcsApoXc=4p_e5mbs9vQCDPHDLrdt-8bd5D_5XhLGYOOJA@mail.gmail.com> <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org>
In-Reply-To: <805143ce-5b15-4944-eb12-80d4d3b365d3@babelouest.org>
From: Thomas Broyer <t.broyer@gmail.com>
Date: Sun, 4 Oct 2020 17:27:41 +0200
Message-ID: <CAEayHENEcr21QHNF9ATupiRwbwBNJfi2kEryGR8A2=UL2JUckQ@mail.gmail.com>
To: Nicolas Mora <nicolas@babelouest.org>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000045663905b0da02f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KS_uITdyEejB_wZLUcRog4J1A6g>
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: Sun, 04 Oct 2020 15:27:54 -0000

Disclosure: I have not read the draft on JWT AT, those comments are based
only on my current knowledge of OAuth 2.0 / OpenID Connect, and JWT.

Le sam. 3 oct. 2020 à 19:18, Nicolas Mora <nicolas@babelouest.org> a écrit :

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

With a JWT AT you can check the JWT signature and detect expiry without
introspection.
But otherwise, yes, no difference.

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.


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
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>