HTTP Digest Authentication RESTful?

[redskins80]

I am trying to create a RESTful SMS API which only requires the consumer and the provider to authenticate (no user since user data is not being stored, another word for this would be 2-Legged Auth). I was wondering if I could use the HTTP Digest Authentication to make secure requests. I could easily use PHPs curl library to authenticate developers' apps without having to display the ugly login box thrown by the browsers.

But my main issue is -

1) Is using Digest auth restful?

2) What are its shortcomings wrt APIs

3) Since users cant be logged out of systems using digest auth (no clean method of logging out exists), is it ok to keep the session intact till the users' app/browser is closed? This would mean the users' application can fire up many requests later on without authentication (which isnt necessarily a bad thing if its the same user).

[Vaidik Kapoor]

I am working on designing a RESTful API for a project and I have faced similar dilemmas with authentication issues. So far, I have come to realize that Digest does fix a lot of security related issues in Basic but it has issues of its own as well. One problem is that any secure application (including yours) will save user credentials in a database and passwords will be hashed (at least that's what everyone does and that's what I would suggest you as well). So in case of Digest Authentication, there will be no way for the server to authenticate the client as the client will provide the username and the password (hashed according to Digest's scheme) and the server should be in the position to generate exactly the same hash which it cannot unless it has the plaintext password.

Browsers throw those ugly boxes in case of Digest and Basic because that's the most simple way of implementing Digest and Basic. You can always use script to get rid of that. Also, Basic is not secure (and I am guessing that's the reason why you enquired about Digest). You may choose to use Basic+SSL if security is a concern. Basic alone shouldn't be used anyways as it exposes passwords as plaintext.

- Vaidik

[franco]

I would avoid using HTTP digest for an API. For one thing, HTTP digest
relies on MD5 which is considered broken now.

Consider using the client creds OAuth grant type. This is very simple,
two legged (as you require), and standard based. Of course, during the
handshake, you still need to authenticate. I would normally use HTTP
Basic over SSL for that part.

Another approach would be to just use HMAC signature based on the
shared secret between the consumer and the API. This post might give
you some ideas: http://bit.ly/KeAcfa.

-fl

[Daniel Roop]

+1 the OAuth Client Credentials flow for this one.

[Gabor]

Vaidik,

I can't see why the server should generate hashes upon authentication. All it needs to store in the database is the hashed value that it retrieves from the DB based on the username and compares with the received value.

Gabor