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