On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav <[email protected]>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" <[email protected]> wrote: > > > > On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <[email protected]> > wrote: > > > > > On 4/6/10 5:24 PM, "Evan Gilbert" <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
