Dimitar,
Using SSL gives you transport-layer security, but is no help at all for authentication, unless you're using client certificates (in which case there still _is_ per-session state, but it's hidden behind the SSL sessions maintained on both client and server). However, as much as this is a convenient approach from a security perspective, it isn't particularly easy to maintain; a great many shops prefer username/password authentication, so some kind of password hashing remains necessary.
I agree that RESTful APIs are generally stateless, but RESTful APIs which use a layer such as OAuth (for authorization, not authentication) are very, very far from unheard of -- Twitter, Facebook, and many, many others take this approach.
On Sat, Mar 17, 2012 at 3:54 PM, Dimitar Popov < Dimitar.Popov@uni-konstanz.de> wrote:
Am Samstag, 17. März 2012, 15:38:49 schrieb Charles Duffy:
So -- I might implement this eventually, as a spare-time thing. The first thing that concerns me -- something strong, like bcrypt, will make the REST interface, with its per-command authentication (lack of sessions) unworkably expensive, so there should be some forethought into how we'd want to handle session management and expiration for the REST
API.
One of the main features of a RESTful service is being stateless. The only proper way of secure authentication is using HTTPS - after all, the that's the main reason why it was invented ;)
Regards, Dimitar