The AS knows the RS's that will consume it's tokens because it knows the
scopes that it can allow the user to authorize. I don't think the AS
MUST know the endpoints of the RS (which is what the current drafts
require).
It is not often that the entity/group responsible for the Authorization
Service is also responsible for the actual resource server. Take for
example a Mail API run by one team and the Authorization server managed
by the Identity team.
Requiring the Mail Team to notify and coordinate the change of endpoints
for a new deployment is brittle.
Also, I believe the main reason for wanting to bind a token to an
endpoint is to protect the token from being sent to a malicious RS and
then having that RS replay the token. If possible replay of a token is
the main concern, then why not use PoP which ensures that only the
appropriate client and present the token. This seems a much cleaner way
to protect against this threat.
Thanks,
George
On 2/25/16 2:02 AM, Manger, James wrote:
> I'm concerned that forcing the AS to know about all RS's endpoints
that will accept it's tokens creates a very brittle deployment
architecture
The AS is issuing temporary credentials (access_tokens) to clients but
doesn’t know where those credentials will work? That’s broken.
An AS should absolutely indicate where an access_token can be used.
draft-sakimura-oauth-meta suggests indicating this with 1 or more
“ruri” (resource URI) values in an HTTP Link header. A better approach
would be including a list of web origins in the token response beside
the access_token field.
--
James Manger
*From:*OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George
Fletcher
*Sent:* Thursday, 25 February 2016 6:17 AM
*To:* Phil Hunt <phil.h...@oracle.com>; Nat Sakimura <sakim...@gmail.com>
*Cc:* <oauth@ietf.org> <oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
I'm concerned that forcing the AS to know about all RS's endpoints
that will accept it's tokens creates a very brittle deployment
architecture. What if a RS moves to a new endpoint? All clients would
be required to get new tokens (if I understand correctly). And the RS
move would have to coordinate with the AS to make sure all the timing
is perfect in the switch over of endpoints.
I suspect a common deployment architecture today is that each RS
requires one or more scopes to access it's resources. The client then
asks the user to authorize a token with a requested list of scopes.
The client can then send the token to the appropriate RS endpoint. The
RS will not authorize access unless the token has the required scopes.
If the concern is that the client may accidentally send the token to a
"bad" RS which will then replay the token, then I'd rather use a PoP
mechanism because the point is that you want to ensure the correct
client is presenting the token. Trying to ensure the client doesn't
send the token to the wrong endpoint seems fraught with problems.
Thanks,
George
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
