We have run into and come up with a specific solution this problem on Photobucket, since we require photo album operations to happen on the appropriate 'silo' the user is on (our sharding technique). We redirect the consumer to the appropriate subdomain to complete their request, even on a POST.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Both 301 and 307 (we're using 301, since we intend for the consumer to forever use the URL provided in the location and the structure'd payload) have a note about the redirect after the POST should be confirmed by the requester. Now, only 303 says that the POST should be converted into a GET during redirect via HTTP/1.1, and none say that the payload of a POST or PUT should be discarded. I don't however see that redirect-after-post is disallowed outright... So, we 301 with location and a detailed payload message to the appropriate place. We're specifically NOT re-signing the request for the redirect target, because we're forcing the OAuth base-string URI to be more of a 'realm resource' rather than the exact request URI. For all types, (GET,PUT,POST,DELETE), we're asking the consumer to fully resend the request. Yeah, this goes against most OAuth implementations, but not against the 1.0 spec as far as I can read. Most of the existing OAuth libraries, if they're tightly tied to a request strategy (annoying... how are you going to sign XMPP?), are currently modified easily to support this. But I get off track. Because we're not re-signing we only expose the original one signed request that could be intercepted (and used once, via nonce checking). Of course, thats a bit out the window if one is using PLAINTEXT. We also hope that the client is checking that the domain is still photobucket.com. The client security could be enhanced by doing a 'signback' in the response payload, ensuring that the response came from the SP they intended, which would be a transport-level security check. Of course, the transport could have some measures built in too (HTTPS cert checking). These checks (domain, signback, https) should fufill the 'confirmed' clause in the HTTP/1.1 RFC. I've struggled with the fact that we must be doing these redirects - we do offer the user the appropriate subdomain/silo information during the login process and from a global resource, but it is very convenient to support the redirects. But other than that, even a proprietary request auth scheme is going to have the same issues over plain HTTP. HTTPS with certificate checking is still the best, but also heavyweight to require. On Nov 24, 8:38 pm, Sam Quigley <[EMAIL PROTECTED]> wrote: > On Nov 24, 2008, at 12:34 PM, Brian Eaton wrote: > > > On Mon, Nov 24, 2008 at 11:59 AM, John Kristian > > <[EMAIL PROTECTED]> wrote: > >> It would be nice if OAuth client libraries automatically handled > >> redirects and signed each request. > > > Wearing my security hat... automatically signing redirect URLs is > > risky. What if the response from the service provider is compromised? > > > If you're using plaintext signatures, you leak your secrets to > > wherever the attacker redirects you. > > > If you're using HMAC or RSA, you leak signatures for whatever URL you > > are redirected to. The attacker can force you to make near-arbitrary > > signed OAuth requests. > > This seems to me like a really serious problem. I think future > versions of the spec should probably say something explicit and > strongly worded about this -- "unless transport-layer security is > being used, consumers MUST NOT automatically follow HTTP redirects" or > something of the sort. Of course, systematically not following 300s is > likely to break other things -- but that seems the lesser evil. > > -sq --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
