3 ms·
It's certainly not dead when it comes to RESTful web services APIs. It's often the best choice for authenticating these. In a browser context, most of the UI c
by mjw 16y ago
It's certainly not dead when it comes to RESTful web services APIs. It's often the best choice for authenticating these.
In a browser context, most of the UI criticisms have little to do with the protocol itself and could be easily addressed if browsers would add a little more HTML + javascript API support for doing HTTP auth logins and logouts. Admittedly that looks unlikely to happen in the near future, which is a shame IMO. IIRC they were considering it at one point for HTML5.
- tptacek 16y agoI feel like I could win an argument that it's never the best choice for authenticating RESTful services, because it implies that authentication is username/password based, and there are often better idioms for app-to-app / company-to-company authentication than usernames and passwords.
- mjw 16y agoGotcha. Is there not any scope for improvement on this front using alternative HTTP auth schemes though? (As far as I'm aware the standard has room for schemes other than Basic and Digest, although I suppose limited to the challenge-response format) At any rate, it'd be nice if there was an effort to work with the HTTP standard (or if not possible, propose extensions to it) and aim for clean protocol design where at all possible when driving to improve API security. SSL + HTTP Auth has been pretty good for us, and it's a good fit for the RESTful design goals of the protocol, so I'd be sad to see it thrown out, rather than improved where necessary.
- tptacek 16y agoSeriously: the opposite of this sentiment is true. We should be working to hoist stuff out of HTTP. Authentication is a perfect example of something that endpoints should be able to decide without having their options influenced by the protocol. If there's a single advantage to conveying a username/password in a dedicated HTTP header as opposed to any other way of using HTTP to convey the same information, it hasn't been well articulated to me. Down with HTTP Authentication!
- defen 16y agoI think you're right. If you look at the standard HTTP header fields, almost all of them demand/specify information about the resource itself, its representation, or the mechanics of the transfer thereof. The others: Host - necessary for multiplexing over the predominant transport protocol Date - necessary for caching Referer - mostly useless and optional anyway User-Agent - information about the client and essentially useless Server - useless And then there are the bastard children: Cookie/Set-Cookie - used to turn HTTP into a stateful protocol Authorization/WWW-Authenticate - used to transmit information about the relationship between the client and server.
- IgorPartola 16y agoUser-Agent is far from useless. When filling out support forms wouldn't you rather skip all the annoying questions about your OS and browser?
- defen 16y agoGood point - it's become the de-facto way of communicating client capabilities to the server.
- mjw 16y agoWell, I think you'd want to think carefully before pulling things out of HTTP and forcing HTTP to sit on top of a stateful, session-based protocol in order to achieve them. The statelessness of HTTP is one of its major strong points, making it easy to load-balance and scale, more easily compatible with a wide range of middleware, etc. The redundancy involved in repeating certain headers is a design trade-off made for a reason. There's a bunch of trade-offs here in the protocol design though, evidently. Coming at it from a security perspective seemingly leads to a different view of those tradeoffs than (say) Fielding has. If you have an application with a really pressing need for stateful session-level protocol features though -- perhaps HTTP isn't the best choice anyway?
- kls 16y agoIt's often the best choice for authenticating these SAML is a better auth mechanism for REST services.