Don't you have larger problems if your protected resources are compromised? You might want to revoke access tokens or take the Google/Yahoo! model of them expiring frequently with refresh tokens.
On Thu, May 6, 2010 at 11:09 PM, Manger, James H < james.h.man...@team.telstra.com> wrote: > David said: > > > Why wouldn't the client send the token with the new request? If I'm > trying to access https://api.example.com/pr?access_token=loin21op and I > get a 301 response, I'll need to follow that if I want any chance of > accessing the protected resource. > > > > > > If https://api.example.com/pr?access_token=loin21op responses with > “Location: http://evil.com/log” should the client get http://evil.com/logor > http://evil.com/log?access_token=loin21op? Surely the later is potentially > insecure. I don’t think we can assume (mandate) that services only redirect > to “good” sites. We certainly can’t assume (mandate) that links in the > content on the response are to “good” sites. > > > > The answer is a bit easier if the token is passed as a query param (like > with Facebook) -- as the client could rely on the service to include or omit > the token param in the redirect/link URI as appropriate. It is less obvious > with an Authorization header, or POST is used. > > > > -- > > James Manger >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
