Hi Sergey, one comment inline
On 3/15/2016 9:31 AM, Sergey Beryozkin wrote:
Hi John, Justin
On 15/03/16 13:12, John Bradley wrote:
Access tokens are opaque to the client not the RS.
But only if they are self-contained as in the option 1 below, right ?
No. They're non-opaque to the RS in all cases. In that, the RS needs to
be able to figure out what information the token represents. That
doesn't mean that the RS can *parse* the token, but it needs to be able
to find all associated security info about the token (scopes, users,
clients, expirations) in order to make it work.
You have three basic design choices.
1 Use a token that the RS can locally validate. JWT or SAML are
standard options or you could do your own custom format and use a
HMAC to integrity protect them. If using astandard token format this
supports multiple AS.
OK.
2 Use a completely opaque token and introspect it at a known AS.
This supports one AS
OK
3 Hybrid use a JWT that contains an issuer as the token but with a
single opaque claim that is used as a ID by the AS. The RS receives
the token looks at the issuer and sends the token to the issuer for
introspection. The introspection endpoint checks the signature and
looks up the reference to provide the introspection response as in
2. This supports multiple AS.
I think Juston was recommending 3 as something he has done.
Thanks for clarifying it, that was what 'jti' was for I believe, very
interesting, I did not get the first time I read it for sure :-).
But this is a non-interoperable solution, right ? I.e, it depends on a
given AS preparing a token this way, would other AS be able to do it
too ?
Thanks, Sergey
John B.
On Mar 15, 2016, at 10:01 AM, 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 ?
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.
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.
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.
Thanks, Sergey
_______________________________________________
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
