Hi Justin
On 15/03/16 13:18, Justin Richer wrote:
And don't forget option 4: look it up in a database because the RS and
AS are in the same box.
Sometimes I feel like I understand OAuth2 and today I'm feeling like
I've no idea what it is :-).
Are AS and RS meant to be collocated ? I thought it was a demo situation
only :-)
Cheers, Sergey
-- Justin
On 3/15/2016 9:12 AM, John Bradley wrote:
Access tokens are opaque to the client not the RS.
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.
2 Use a completely opaque token and introspect it at a known AS. This supports
one AS
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.
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
