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

[Nicolas Mora <[e-mail]>]

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