On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora <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.
>

Well, you were the one saying that “the advantage of using a JWT AT is
close to 0” 😉
(and I was the one bringing the advantage of being able to do some
verifications prior to contacting the introspection endpoint, btw)
In any case, for an opaque AT, you only get to introspect it once to know
its expiration (and you can cache the result); so those preliminary checks
you can do with a JWT only save you one introspection request IFF the token
is not valid, e.g. expired; if it's valid or has been revoked, then you'll
have to introspect it anyway.
And if you imagine that "pushed events" mechanism, then it would work the
same for an opaque AT or a JWT AT, saving you the introspection requests
that would otherwise be mandatory for checking revocation.

So (and I know it wasn't the original subject of the discussion), a JWT AT
can save you, compared to an opaque AT:
 * a call to the userinfo endpoint if it embeds the claims you need
 * a call to the introspection endpoint if it's expired or otherwise
invalid, and/or some memory/storage space that you could use as a cache for
that information for an opaque AT (to avoid issuing other introspection
requests, as an optimization / compromise)

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to