How is that different than using the authorization header? EHL
From: Kris Selden [mailto:kris.sel...@gmail.com] Sent: Friday, May 28, 2010 3:46 PM To: Eran Hammer-Lahav Cc: Brian Eaton; field...@gbiv.com; OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Except you are in control of your web server so you know you put it there and where it came from right? On May 28, 2010, at 3:35 PM, Eran Hammer-Lahav wrote: That's the same thing (in a header or in the attached signed blob). EHL From: Kris Selden [mailto:kris.sel...@gmail.com] Sent: Friday, May 28, 2010 3:21 PM To: Brian Eaton Cc: Eran Hammer-Lahav; field...@gbiv.com<mailto:field...@gbiv.com>; OAuth WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: Re: [OAUTH-WG] FW: Duplicating request component in an HTTP authentication scheme Can't you always have the front end web server preserve the original URI in a header or something before the rewrite engine or application framework mangle it, right? For example, this Nginx conf that preserves original parts of the request that get changed when the request is proxied to the upstream web server: proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_set_header Host $http_host; Or even writing a module that validated the signature and intended target directly in the web server before the app framework. I guess this makes in hard to write a complete drop-in solution just on the app framework but that doesn't seem like a good idea anyways. Seems like libraries that do different modular pieces OAuth are a lot more useful rather than "plugin" library deciding something like you should write a nonce to a MySQL DB table every request. On May 28, 2010, at 11:02 AM, Brian Eaton wrote: On Thu, May 27, 2010 at 10:51 PM, Eran Hammer-Lahav <e...@hueniverse.com<mailto:e...@hueniverse.com>> wrote: Cool. Glad we can put Roy's security concern to rest, at least. I disagree. Your signature proposal makes matching worse, but moves the "canonicalization problem" to the server side. You just flipped the problem. The client gets much simpler but the server gets potentially less secure (as a likely result of poor implementation). You raise a bunch of really good points in your response, and I'm going to ignore almost all of them for now. =) I want to get to the heart of the "potentially less secure" statement. In OAuth 1.0, in order to be secure, the server had to check a signature. [1] Under the proposal I made earlier, the same server will need to check a signature, and it will also need to check the intended target of the signed message. That is *not unusual* in authentication protocols. OpenID, SAML, and others all have the exact same requirement. It's documented in their security recommendations. And there are compliance tests that verify that servers do check this. If someone fails to make this check, it will be revealed as soon as anyone looks at their code or tests their server. Cheers, Brian [1] Aside: secure servers actually need to do lots more than check signatures. They need good user management, and key management, and XSS-prevention, and XSRF-prevention, and patch management, and physical security, and so on. But that's out of scope for an authentication protocol. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
