This is fixed (back) in -11. EHL
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Kristoffer Gronowski > Sent: Tuesday, October 26, 2010 10:19 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Draf 10 OAuth chapter 2.1 question > > Hi! > > Just wondering for clarification on the example. > > For example (line breaks are for display purposes only): > > > POST /token HTTP/1.1 > Host: server.example.com > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > Content-Type: application/x-www-form-urlencoded > > > grant_type=authorization_code&client_id=s6BhdRkqt3&code=i1WsRn1uB1& > redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > Alternatively, the client MAY include the password in the request > body using the following parameter: > > client_secret REQUIRED. The client password. > > For example (line breaks are for display purposes only): > > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_code&client_id=s6BhdRkqt3& > client_secret=gX1fBat3bV&code=i1WsRn1uB1& > redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > When searching for the password should also the user part be used? > If you Base64 decode czZCaGRSa3F0MzpnWDFmQmF0M2JW you get: > s6BhdRkqt3:gX1fBat3bV > > So it is sending client_id:client_secret. > In that case the FORM has a redundant client_id parameter. > Should an implementation search for client_id in the basic header or not? > > If not I guess that a valid basic auth header could be just :client_secret or > in > this case :gX1fBat3bV? > > Might be good with a clarification here. > > BR Kristoffer > _______________________________________________ > 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
