Hi James, On Mon, May 10, 2010 at 5:36 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: > Marius, > >> But then again, how does the client end up making a request to > the wrong site? > > The client follows a redirect or link. It doesn't know if the ultimate source > of the new URI was the resource server’s internal logic, user-generated > content, or a parameter in the request URI (eg an open redirector).
If the protected resource sends a redirect instead of serving the resource then probably it knows what it is doing. Following links, how do you see that happening? Normally a client will not follow links without understanding them and at the same time send access tokens. All I am saying is that IMO it is not very likely that redirects and links will cause tokens to leak. I do agree that "sites" can help in these cases, just not sure it is worth the complexity. >>> If the wrong site uses HTTP then the token is also exposed on the network >>> -- so it has just been broadcast in the clear if you are using public wifi. >>> Again a security failure. > >> Sure, but the "sites" parameter does not help in these cases. > > "sites" does help. If its value was: > "sites": ["https://api.example.com";, "https://img.example.com";] > Then no HTTP URI matches so the token is never sent in the clear. Yes, but HTTP and WIFI can compromise tokens even if sent to the proper sites. Right? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
