It's not really up to the client. If https://api.example.com/pr?access_token=loin21op redirects to https://api.otherapi.com/somethingelse?access_token=loin21op, then I just need to follow the redirect - no decisions to be made by the client. Many low-level HTTP libraries will just do this automatically. There are already facilities to warn if you try to redirect from an https url to an http one.
I think the difference between your cookie example and OAuth token is that cookies are automatically sent on every request, so there have to be rules about when they are automatically appended. OAuth access tokens aren't the same thing - they are explicitly added by developers on each request, so we don't need to overspecify rules in the protocol that should be handled by developers. On May 6, 2010, at 10:35 PM, David Recordon wrote: 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. Maybe we're saying the same thing? On Thu, May 6, 2010 at 10:21 PM, Manger, James H <james.h.man...@team.telstra.com<mailto:james.h.man...@team.telstra.com>> wrote: How should an OAuth client app behave when it gets an HTTP redirect on requesting a protected resource? Similarly, how should it behave when it follows any other link in a response? Obviously it should make a new request to the URI in the redirect or link — that is normal HTTP and hypertext behaviour. The question is does the token get sent with the new request? I think the spec needs to provide an answer, even if it isn’t my suggestion of an “sites” list when a token is issued. -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <ATT00001..txt>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
