Best authentication mechanism to access RESTful webservices

Question

I'm designing restful webservice which will be used by 3rd parties.They need to be authenticated to use my Restful service.For that i'm planing to use two approach to authenticate them.

1. Using another Restful service as a proxy to access the Restful services: To access the RESTful service the user will send the username and password to this proxy class in POST method.When the username and password is correct a unique id(say, authentication key) will be generated and is sent in the response.When the next request is made,the user will send the authentication key (and other details to access the target Restful service) in the request payload.This authentication key will be validated by the proxy.If the key is valid ,the proxy will invoke the target restful service and return the response to the client.Otherwise error message will be sent in the resonse.

2. Servlet based authentication: Same as first approach but servlet will act as a proxy to access webservices.In this approach username and password will be validated by the servlet and if it is correct,the servlet will set some cookie in the response and send it to the client.Next time the when the user sends request cookie will be validated.If it is valid then the servlet will invoke the Restful service and sends the response.But i'm not sure whether the user request will contain cookie or not.

In first approach the user needs to send the authentication key for every request. But in second approach it is not needed.

I need to know which approach is better?..and also any other way to handle this..

Answer 1

I'm not an expert in servlets or Java to be honest, I know how to do a good amount of things in Java but it's not my main environment. However, I do know a lot about security specially REST.

Your first approach is the classic one and it doesn't require a Proxy. It works pretty well indeed, but you could simplify it not having a Proxy service.

The second one is not recommended. There are several articles indicating many problems in cookie-based solutions. In fact, they're easier to impersonate and obtain illegal access. You never send a cookie anyway, you're sending for sure a header that contains some information of the cookie. Keep in mind you ALWAYS send the authorization information somehow with these mechanisms. No matter how you do it and whether or not is transparent for the client, the authorization MUST travel because the main principle of REST is stateleness:

Every single request to the Api happens in complete isolation. ... it’s not correct to coax the server into a state to reach a page

Quoting my own words to my team.

In terms of using a very well-known method, I'd go with OAuth 2.0 which is widely used. The concept is similar to your approach emiting a bearer token as the result of the security negotiation:

http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html

The token itself contains a lot of information and there are several articles about them in terms of sensitive information you could expose.

A way better mechanism is using public-key cripthography, the server can emit a signed-message you could validate with the public key but this approach exceeds the scope we can tackle here in a small answer.

It always depends on how sensitive is your service, there's always a trade-off in terms how secure you need to make it and how much resources and time you can spend.