Authentication for REST web services

Question

I'm starting to design a REST web service, and am unclear on the best approach to authentication. The service will allow individual users to access/manage their own data, so some type of user authentication is required. I've been looking at these options:

• OAuth

OAuth seems to be more about authorisation instead of authentication. I plan to handle authorisation natively within the services, so am not looking for a solution to this. But, is OAuth also appropriate for authentication?

• OpenID

OpenID certainly provides a solution for authentication, but this is geared more to allowing users to use their 3rd party credentials (Google, Yahoo, etc.) Though I would like to support this, this is not a primary concern for me, and I will definitely allow users to sign up with native credentials (email/password).

• HTTP Basic authentication

This is simple to implement, but it's my understanding that this may not be a very secure method. Also, it would seem to require the exchange of credentials for each access, but I'd prefer that the user authenticate once and then continue access via a session token.

• Custom authentication

Basically, roll my own login/token generation service, and require a valid token for access to all other resources (obviously, everything would be over SSL).

---

As well as creating the web services, I'll also be building a client (web) application which uses these services on behalf of a user, but I don't want the application to have to store user information/credentials/etc. So, something like this:

User (authenticates with email/password or 3rd party credentials) --> Web application (authenticates with application ID) --> Web services

And again, I want to allow others to build clients as well, so the middle tier can be any 3rd party application:

User (authenticates with email/password or 3rd party credentials) --> 3rd party application (authenticates with application ID) --> Web services

My very top-level requirements are:

• Secure (obviously)
• Native credentials
• Support for 3rd party credentials (Google, Yahoo, LinkedIn, etc.)
• Support multiple clients (web app, mobile app, 3rd party apps, etc.)
• Client credentials (just an app ID?)
• Login sessions that expire
• Authorisation is NOT required

So, my question is, based on the above (please let me know if this is too vague), is there a "best" approach? Are OAuth or OpenID appropriate, or am I making this too complicated, and instead should just roll my own authentication?

EDIT:

I think I will need to implement the following:

1) Native credentials/tokens (HTTP basic auth over SSL?)

2) An OpenID "Relying Party" to allow my api to use OpenIDs hosted elsewhere (i.e., "support for 3rd party credentials")

3) An OAuth "Consumer" to allow my api to access 3rd party services (like accessing a user's LinkedIn profile).

4) An OpenID "Provider" to allow people to use the api's native IDs elsewhere (optional)

5) An OAuth "Provider" to allow 3rd party apps to access my api on users' behalf (optional)

Does this seem right, or am I making this more complicated than it needs to be?

Answer 1

You could consider JWT (JSON Web Token) see JWT draft rfc. It would certainly meet your security and session expiration requirements. However being a draft standard it's unlikely to be widely used right now, this could change soon since JWT are part of OAuth 2.0. JWT are easy to implement in most languages and there are plenty of libraries already. As a simple explanation, a JWT token consist of 3 parts , the header , body and signature. The header and body are json objects being basee64url encoded (alphabets differ from base64 by the 2 last characters) and then signed with HMAC256 (or another algorithm specified in the header) the RFC explain how to exactly generate this signature. You might want to check this online token generator.

JWT are http headers and query parameters friendly.

Answer 2

One of the good option to consider is 'Shared key Authentication'. This is the type of authentication that Amazon web service and Windows Azure Storage service uses. We have used Shared Key Authentication in the REST service we developed. You can do a quick search in Google for 'Shared Key authentication' you will get lot of details.

I wrote one blog post here about this.

High level steps are:

1. Client combines a set of unique data (elements) defined by the REST service.
2. Sign this combined data using a key only known to client and REST service
3. Send this signature to REST service as value for HTTP Header
4. REST service compute the signature exactly the same way client did
5. Compare signature sent by client with the one computed, if same assume its a valid request else deny the request