Hi Justin
I guess it depends on what the customer requirements are, with the AS
vendor neutrality being one of the variables - something that we had to
deal with recently.
Or if the RS stack is flexible in a way that it can be easily adapted to
work with AS from multiple vendors. I can see how it works.
Thanks, Sergey
On 15/03/16 13:36, Justin Richer wrote:
On 3/15/2016 9:35 AM, Sergey Beryozkin wrote:
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
They're conceptually separate, but they can be served by the same
machine and therefore have trusted, proprietary, back-end communications
between them that don't need to be interoperable. It's not just for
demos, and it's actually one of the most common (if not the most common)
deployment of OAuth 2.
-- Justin
-- 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
