On Tue, Mar 15, 2016 at 6:23 PM Justin Richer <jric...@mit.edu> wrote:
> +1 to all of this. > > Our reasoning for the JWT+introspection was to allow for an RS to take in > tokens from multiple AS, by looking up the issuer in the JWT itself. > But then, as I said, you need the AS to "cooperate" by making their ATs JWTs; only for one RS that want to also accept ATs from other (concurrent?) ASs. They could make everyone pay the price with bloated tokens, or start treating some RSs different from others (at registration time, say you want JWTs), or add extensions to the authorization endpoint or token endpoint so clients can ask for JWT tokens. Overall, I think my proposal to exchange an AS token for a RS-specific token at an AS-specific endpoint at the RS (see mail in the other thread from last week; that phrasing here is “fun” but not really legible ;-) ) would have the best of both worlds. At the RS, linking the issued token with the received token from the AS allows the RS to introspect the original token from time to time to check for revocation (possibly in addition to its own revocation mechanism for its own tokens). Downside is that clients now have to do the token exchange and keep track of both tokens. > — Justin > > On Mar 15, 2016, at 12:34 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > > On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin <sberyoz...@gmail.com> > wrote: > >> Hi >> >> After following the recent thread on multiple authorization servers, but >> also reading some other related threads, I have a question related to >> when the token introspection can be avoided. >> >> My understanding has been that given that access tokens are opaque the >> RS does not know anything about its content, hence that was the purpose >> of the token introspection spec: provide an interoperable way for RS to >> submit a token to AS and get the token data for RS to make a final >> decision about this token. >> >> I think if the access tokens are really opaque, i.e, they are sequences >> RS can not look into, then having the introspection option is the only >> way to check what the token is really about. >> >> But the recent replies with respect to using JWS or JWE tokens have >> confused me. >> >> 1. AccessToken as JWS JWT Token: >> >> RS can easily look into it, but Justin mentioned that in one case they >> first validate this JWS token and then forward it for some further >> introspection. Why start introspecting if the token has been validated >> and its content is visible ? >> > > Because you want to know whether it's been revoked before its expiration. > Introspection is the only way (unless AS and RS are colocated), as only the > AS knows. > > >> Perhaps because some token data which are sensitive are only visible in >> the introspection response ? If yes then why use a self-contained token >> if some more external data are associated with it. >> > > If the token is not valid (bad issuer, bad signature, expired; or if the > scopes are included: insufficient scopes), it saves you a request to the > introspection endpoint ;-) > Only if the token passes the first checks would you introspect it to see > if it's still active (not revoked) and possibly retrieve more data about it. > > >> 2. AccessToken as JWE JWT Token: this option was mentioned a couple of >> times recently, Jonh B. suggested in the other thread the introspection >> may not be needed (sorry if I misread it). >> The question here, how can RS deal with a JWE token, it would need to >> share the decrypting key with AS. >> > > I think that was the idea yes (didn't someone commented on the thread that > they deployed JWT tokens with shared secrets or symmetric keys?) > > >> So, is introspection needed only for the completely opaque tokens or it >> is also needed for JWS and JWE tokens. I'd say it might be reasonable to >> skip it in case of JWS, depending on the specific requirements (as the >> expiry, issuer, will be typically set in JWS JWT), while with JWE I can >> not see how RS can avoid introspecting unless it shares the >> secret/private key with AS. >> > > As Justin mentioned in the other thread: introspection is useful > (required?) for checking the "liveness" of the token. > > Side-note: given the size of a JWT compared to some "simpler", opaque > tokens (mere identifiers), and the fact introspection response are likely > to be cached for a few minutes by the RS, I wonder if using a JWT so you > can possibly avoid an introspection request outweights (sic!) the bloat of > a JWT sent repeatedly over the network (possibly a network with high > latency, low bandwidth, and sometimes paid based on exchanged volumes). > This is rhetoric actually: I side on the "small token that require > introspection" until someone comes with a compelling argument to go the > other way. > > _______________________________________________ > 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
