I'm not seeing how client id helps if a proxy server is somehow involved with inserting the bearer token as the researchers suggested.
Phil On 2012-06-29, at 11:30, John Bradley <ve7...@ve7jtb.com> wrote: > I think they only exploited the implicit flow. > > My point was that there is a way you could do the same thing with code if it > is a public client that is not authenticating to the token endpoint. > > In general making identity assumptions in the client based on a code or > access_token has risks that are out of scope for OAuth. > > We do however want to provide good advice about specific things that can > leave systems insecure when using OAuth. > > John B. > > On 2012-06-29, at 2:22 PM, Phil Hunt wrote: > >> I'm not clear whether the MS Security Researcher hack was with the >> authorization code or the access token. If the latter, the client_id is out >> of the picture isn't it? >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> On 2012-06-29, at 11:14 AM, Dick Hardt wrote: >> >>> >>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote: >>> >>>> It is nice to know that I may occasionally be correct:) >>> >>> You must be delighted when it happens! ;) >>> >>>> While you may assume that it is reasonable for a client with a code to >>>> make a request to the token endpoint including it's client_id and the >>>> server to only give out the access token if the client_id in the token >>>> request matches the one in the original authorization request. However >>>> the spec specifically doesn't require that. >>> >>> I think that is an error in the spec and should be changed, or text adding >>> saying that the client_id SHOULD be checked. >>> >>> -- Dick >>> _______________________________________________ >>> 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
