From nobody Tue Oct 6 14:25:39 2020 Return-Path: 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 1173B3A14F4 for ; Tue, 6 Oct 2020 14:25:39 -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 Wo86Ae8RfZiM for ; Tue, 6 Oct 2020 14:25:37 -0700 (PDT) Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) (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 01C7E3A10C0 for ; Tue, 6 Oct 2020 14:25:36 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id ce10so19784295ejc.5 for ; Tue, 06 Oct 2020 14:25:36 -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=q9neRA53nwPRk/t42SZxz6bwiz5Uvwukilui8uXNpmw=; b=r/9e4IEqdlsRk7uu2HIyxDxDpbwQBe4b4/LIKJUtq+omkf0HcO6g5gDPcpi3WwXlt6 QqhkeAVqxn155DHl8E3lH34HGvDwNQ1cXAh0aFxRgl5Q3vm5lqEtrmOQQSCT5feAGj47 8PRY+F5PNfLsYDYBHMKB/D0qQ3Ea3WpqqmkHorf5UJ3KM8WbnNigFqWpi5JYsMZ3ErCU t2swINRw0AsQTlWfzmckh46CYF3XiE0LgLIN1wrfLzgbAGR6cXTKes98zbpeSkA7/dIs lgjSxwdyuC+u+U2J/4mAE/R19sSpmItB4UqqPqQELJeE+bMDwXwlS6JHA9DRDQx1O5ck TxYA== 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=q9neRA53nwPRk/t42SZxz6bwiz5Uvwukilui8uXNpmw=; b=gxQw6i45isoA7c7JaobF0BAfy2aSeeZ7ZqaRSHyQ0yKVCLbUyYPIC8uaJRkqqdDZ61 YpUxMlb7JvKAmA8P9CTKit682M2PAznWCzCoPhM8Gjq1C0AO7NOQeyF4k3mXsIBT5/DM tA1Nsy6Lsz2e9H/rg1qTkV2lqNMtt4bwEmal8m3PPkvrQ9qj8OMMlnChRG1SOotdxVJL FjNp2WBu+6OhHKVQmSl5AK1n7BakcHEqrPc/egWTLZRIRGxAxcfSYrmLvuV2QQZs37cE dNkoE43qOJpe2p5lDk5tbfic+QPw/UmV6UUw6TEdRQ5vDkyfNDOKauVkATO1+vd2e9YV GffQ== X-Gm-Message-State: AOAM531AKwHuZup4vdu6AQeoCBb0bOWcHxpRwHJvsiKpXOwSiNcctD3H i5gqdxMAMWFKDHKXInp1cqqcK64n5ml929Es/aayyV3SNJo= X-Google-Smtp-Source: ABdhPJzVWHwZ2kx1eajaZVft9HMvpAx6NcGrExKazJ1k1bI2rOSjR21dJKhoeoOm1y/kVp0ryQMFmu5Ls8It2r5avoA= X-Received: by 2002:a17:906:a002:: with SMTP id p2mr1464446ejy.399.1602019535333; Tue, 06 Oct 2020 14:25:35 -0700 (PDT) MIME-Version: 1.0 References: <13035645-B875-48E5-80DC-C1FD401423E2@manicode.com> <060901d69c26$ba2deab0$2e89c010$@auth0.com> In-Reply-To: <060901d69c26$ba2deab0$2e89c010$@auth0.com> From: Andrii Deinega Date: Tue, 6 Oct 2020 14:25:24 -0700 Message-ID: To: vittorio.bertocci=40auth0.com@dmarc.ietf.org, oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000053ad0c05b1073da4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 21:25:39 -0000 --00000000000053ad0c05b1073da4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vittorio and WG, Would it be possible to include something like the following to https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 In case the authorization server exposes the introspection, revocation, and OpenID Connect userinfo endpoints they MUST act in the same way as it happens with a regular access token. That allows the AS to change the type of an access token on the fly and that won=E2=80=99t lead to interoperate i= ssues. Plus, the consumers of these endpoints use them regardless of the type of access token. The way how the AS can notify RSs that the token revocation event happened (if it decides to do so) is completely left to implementers. ? Another minor editorial thing from me is it would possible to change and refer to "JWT access tokens" as AJWT. Thus, this document won't repeat the token word twice. Regards, Andrii On Tue, Oct 6, 2020 at 2:22 PM wrote: > Hey Jim, regarding > > Every logout event should trigger token revocation > That isn=E2=80=99t necessarily the case. An access token represents the a= bility of > a client to access a given resource; the fact that it requires an > authentication transaction/session establishment to be issued to the clie= nt > does not mean that the AT lifetime is tied to the lifetime of that sessio= n. > Say that I allow LinkedIn to tweet on my behalf. Once I have done that, i= t > doesn=E2=80=99t matter whether I stay logged in their web app or otherwis= e. Even if > I log out of the session in which context I got my twitter AT, I can stil= l > 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=E2=80=99t de= fined > today. > > -----Original Message----- > From: OAuth On Behalf Of Jim Manico > Sent: Sunday, October 4, 2020 5:17 PM > To: Nicolas Mora > 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=E2=80=99m mentioning this because a lot of OAuth solutions in the mobil= e space > literally ignore the logout event, such as Facebook=E2=80=99s mobile OAut= h > solution. > > - Jim > > > On Oct 4, 2020, at 6:55 AM, Nicolas Mora wrote= : > > > > =EF=BB=BFHello, > > > >> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit : > >> > >> 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 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000053ad0c05b1073da4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Vittorio and WG,

Would it be poss= ible to include something like the following to https://tools.ietf.org/ht= ml/draft-ietf-oauth-access-token-jwt-10

In case the authorizati= on server=C2=A0exposes the introspection, revocation, and OpenID Connect us= erinfo endpoints=C2=A0they MUST act in the same way as it happens with a re= gular access token. That allows the AS to change the type of an access toke= n on the fly and that won=E2=80=99t lead to interoperate issues. Plus, the = consumers of these endpoints use them regardless of the type of access toke= n.

The way how the AS can notify RSs that the toke= n revocation event happened (if it decides to do so) is completely left to= =C2=A0implementers.

?

Ano= ther minor editorial thing from me is it would possible to change and refer= to "JWT access tokens" as AJWT. Thus, this document won't re= peat the token word twice.

Regards,
Andr= ii

On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=3D40auth0.com@dmarc.ietf.org> wrote:=
Hey Jim, regard= ing
> Every logout event should trigger token revocation
That isn=E2=80=99t necessarily the case. An access token represents the abi= lity of a client to access a given resource; the fact that it requires an a= uthentication 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=E2=80=99t 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 correspondin= g post will show up on twitter as well.
Now, one might choose to *explicitly* tie tokens lifetime to originating se= ssions lifetime, see the discussion on the OpenID Connect group about a pos= sible online_access scope for influencing RTs and Ats (in particular, in th= e context of SPAs) but that's additional semantic that isn=E2=80=99t de= fined 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<= br> Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

> In this model, considering that token revocations don't happen a l= ot...

Just a brief note, a secure piece of software makes the logout feature prom= inent. Every logout event should trigger token revocation.

I=E2=80=99m mentioning this because a lot of OAuth solutions in the mobile = space literally ignore the logout event, such as Facebook=E2=80=99s mobile = OAuth solution.

- Jim

> On Oct 4, 2020, at 6:55 AM, Nicolas Mora <nicolas@babelouest.org> wrote: >
> =EF=BB=BFHello,
>
>> Le 20-10-04 =C3=A0 11 h 27, Thomas Broyer a =C3=A9crit :
>>
>>=C2=A0 =C2=A0 There might be some kind of pushed events between the= AS and the RS when
>>=C2=A0 =C2=A0 a JWT AT is revoked, to allow the RS not to introspec= t a JWT AT at all.
>>=C2=A0 =C2=A0 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, giv= ing
>> almost no advantage to JWT ATs.
>>
> Not necessarily, let's say the AS informs the RS only of the revok= ed
> 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 l= ot,
> the ratio revoked AT/valid AT is very low, so the advantage of a JWT <= br> > is important, because it means not so much communication between the <= br> > AS and the RSs, and a very reliable AT.
>
> But this means a communication mechanism that isn't standardized y= et.
>
> /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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000053ad0c05b1073da4--