Hi,

I admit I used "authentication" in the wrong way; what I meant is "authentication with username/password". That is, I consider the lack of https support a serious obstacle for secure authentication with username/password.

Regards,

Dimitar

Am Samstag, 17. März 2012, 15:58:55 schrieb Charles Duffy:

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