Hi Andrii,

Thanks for the thoughtful comments! Here’s my 2 c.

 

On the proposed language: given that the JWT AT profile is just providing more 
details on the content of an AT, making JWT ATs a proper subset of all ATs, 
readers should have no reason to believe that introspection or any other 
existing spec discussing AT behavior should operate differently. That 
assumption holds for everything across the board, hence it would be a bit odd 
to call out this particular case. On the userinfo case, I would find it even 
more left field to say anything about it.
If we do reach a consensus on specific revocation practices that apply to JWT 
ATs specifically, and we conclude that they should live in this document, I 
will be happy to add language accordingly.

 

On the AJWT: I hear you on the dissonance that JWT AT carries, but I am very 
hesitant to introduce new acronyms to an already crowded/impenetrable domain.
JWT access token might not roll off the tongue, but at this point ‘JWT’ is 
nearly a proprietary eponym and the expression “JWT token” is extraordinarily 
common in literature, a quick google query will give you the full measure of 
the phenomenon, hence I think we’ll be OK with the current form.

Cheers,

V.

 

From: Andrii Deinega <andrii.dein...@gmail.com> 
Sent: Tuesday, October 6, 2020 2:25 PM
To: vittorio.berto...@auth0.com; oauth@ietf.org
Cc: Jim Manico <j...@manicode.com>; Nicolas Mora <nico...@babelouest.org>
Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint

 

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’t lead to interoperate issues. 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 <vittorio.bertocci=40auth0....@dmarc.ietf.org 
<mailto:40auth0....@dmarc.ietf.org> > 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-boun...@ietf.org <mailto:oauth-boun...@ietf.org> > On Behalf 
Of Jim Manico
Sent: Sunday, October 4, 2020 5:17 PM
To: Nicolas Mora <nico...@babelouest.org <mailto:nico...@babelouest.org> >
Cc: oauth@ietf.org <mailto: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 <nico...@babelouest.org 
> <mailto:nico...@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 <mailto:OAuth@ietf.org> 
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org> 
https://www.ietf.org/mailman/listinfo/oauth

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

Reply via email to