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/log or 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
