Re: [OAUTH-WG] OAuth 2.0 Discovery Location

[George Fletcher <[e-mail]>]

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:[e-mail]] *On Behalf Of *George 
> Fletcher
> *Sent:* Thursday, 25 February 2016 6:17 AM
> *To:* Phil Hunt <[e-mail]>; Nat Sakimura <[e-mail]>
> *Cc:* <[e-mail]> <[e-mail]>
> *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
>