On Wed, Apr 7, 2010 at 11:21 PM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> 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.
>
Note: I'm fine with adding a username in the response if it helps from the
security side. It's not clear to me that there's a security hole, but it
never hurts to provide more information in the response back.
> 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
