I will leave this to the security folks to decide but it seems to me that if
the client asks to limit the username of the end user granting access by
specifying it in the request, the server must repeat that information when
issuing such a token. Otherwise, an attacker can force a user to grant
access to another account (for example, if they have both a personal and
work accounts on the same server) without the client being able to detect
it.
In other words, if the client can demand an access token for a specific
username, it should be able to have the absolute confidence (assuming it
trusts the server) that the access token received has that attribute.
EHL
On 4/7/10 10:46 PM, "Evan Gilbert" <uid...@google.com> wrote:
>
>
>
> On Wed, Apr 7, 2010 at 9:29 AM, John Panzer <jpan...@google.com> wrote:
>> I'm assuming that tokens need not be bound to a specific user (typically they
>> are, but imagine a secretary granting an app access to his boss's calendar
>> and then leaving the company and therefore being removed from the calendar
>> ACL, but the app still keeping access by virtue of the capability granted by
>> the token). In this case, the proposed wording seems kind of problematic for
>> a MUST.
>
> Note that the "resource owner" in this case is the secretary, not his boss.
> Resource owner is "An entity capable of granting access to a protected
> resource."
>
> Since access tokens are bound to the resource owner ("A unique identifier used
> by the client to make authenticated requests on behalf of the resource
> owner."), I think in this case the system would have a clear way to revoke
> access to the document.
>
> Updating the wording on the proposal slightly to clarify (also changing format
> to new parameter formatting)
>
> Before:
> username
> The resource owner's username. The authorization server MUST only send back
> refresh tokens or access tokens for the user identified by username
>
> Current:
> username
> OPTIONAL. The resource owner's username. The authorization server MUST only
> send back refresh tokens or access tokens capable of making requests on behalf
> of the user identified by username
>
>>
>> On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert <uid...@google.com> wrote:
>>>
>>>
>>> On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav <e...@hueniverse.com>
>>> wrote:
>>>> What about an attacker changing the username similar to the way a callback
>>>> can be changed?
>>>
>>> I don't think there is a danger here.
>>>
>>> We still use all of the safeguards in place from the rest of the flow -
>>> adding this parameter never log you in when omitting the parameter would not
>>> have. It will just create more error responses.
>>>
>>>>
>>>> EHL
>>>>
>>>>
>>>>
>>>> On 4/6/10 11:14 PM, "Evan Gilbert" <uid...@google.com
>>>> <http://uid...@google.com> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <e...@hueniverse.com
>>>>> <http://e...@hueniverse.com> > wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/6/10 5:24 PM, "Evan Gilbert" <uid...@google.com
>>>>>> <http://uid...@google.com> > wrote:
>>>>>>
>>>>>>> Proposal:
>>>>>>> In 2.4.1 & 2.4.2, add the following OPTIONAL parameter
>>>>>>> username
>>>>>>> The resource owner's username. The authorization server MUST only send
>>>>>>> back
>>>>>>> refresh tokens or access tokens for the user identified by username.
>>>>>>
>>>>>> What are the security implications? How can the client know that the
>>>>>> token
>>>>>> it got is really for that user?
>>>>>
>>>>> Think the client has to trust the auth server, in the same way as with the
>>>>> username + password profile. The auth server can always send back a scope
>>>>> for a different user.
>>>>>
>>>>> Worst case is that there is an identity mismatch between client and the
>>>>> identity implicit in the authorization token. This mismatch is already
>>>>> possible, and I don't think the username parameter makes the problem
>>>>> worse.
>>>>>
>>>>>>
>>>>>> EHL
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
