+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.
— 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 > <mailto: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
