While I understand the desire for small tokens, we chose JWT as a
wrapper for the external AS opaque token so that we would have a generic
implementation that can be expanded to additional partners without
affecting our implementation.
You could assign each AS in a multiple AS closed environment a unique
value and then pre/post-fix it to the opaque token so that the RS could
know where to introspect it. This is still a structured token, just a
binary representation to save size. There are probably better binary
ways to do this:)
Thanks,
George
On 3/15/16 12:34 PM, Thomas Broyer 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
