Marius, > If the protected resource sends a redirect instead of serving the > resource then probably it knows what it is doing.
Sure, the server knows what it is doing. However it is completely legitimate for a server to knowingly redirect to an external site, to a site configured by a user, to a site matching a search term etc. The server knows whether a redirect (or link) might cross a security boundary, but the issue is how does the client know. > 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. A client app understands that’s a URI in an <img> tag or a Facebook "photos" link should lead to an image. It is far less obvious what the security context for that image is: is it part of the same API, or an arbitrary image on the Internet. >> "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? Yes, but only if the server explicitly decided that particular token was suitable for sending in the clear and explicitly told the client so by including an HTTP string in the "sites" field. Marius _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
