2

I'm building some RESTful API for my project based on Play Framework 2.X.

My focus is on the authentication mechanism that I implemented.

Currently, I make use of SecureSocial. The workflow is:

  1. An anonymous user calls a secured API
  2. Server grabs any cookie Id (kind of authentication token) and checks for matching in the Play 2 cache. (cache contains an association between cookie Id (randomly generated) and the user Id, accessible from database.
  3. If any matched, user is authorized to process its expected service.
  4. If none matched, user is redirected to a login page, and when filled with valid credentials (email/password), server stores its corresponding authentication data on Play 2 cache, and sends the newly created Cookie containing only a custom Id (authentication token) to user and of course, secured through SSL.
  5. While the cookie/token doesn't expire, the user can call secured api (of course, if authorized)

The whole works great.

However, after some search, I came across this post, and ...I wonder if I'm in the right way.

Indeed, dealing with cookies ("sessions" in Play's term), would break the rule Restfulness. Because an api really considered as stateless should be called with ALL the needed data at once (credentials/tokens etc..). The solution I implemented needs both calls: one to authenticate, the other to call the secured API.

I want to make things well, and I wonder some things:

  • What about the use of Api keys? Should I implement a solution using them instead of this SecureSocial workflow? Api Keys would be sent at EVERY API CALL, in order to keep restfulness. I think about it since I want my APIs to be reached by some webapps, mobiles and other kind of clients. None of all are forced to manage cookies.

  • What about OAuth? Should I really need it? Would it replace totally the usage of simple api keys? Always with this objective of several clients, this known protocol would be a great way to manage authentication and authorization.

In one word, should I implement another mechanism in order to be Restful compliant?

Community
  • 1
  • 1
Mik378
  • 21,881
  • 15
  • 82
  • 180

1 Answers1

1

this is quite an old Q, but still worth answering as it may interest others. REST does mandate statelessness, but authorization is a common exception when implementing. The solution you described requires a single authorization process, followed by numerous service calls based on authorized cookie. This is analog to api keys or OAuth. There's nothing wrong with cookies as long as the service isn't of high-security nature and that you expire then after a reasonable time. Integrating OAuth into your service sounds a bit of an overkill and is recommended only if you expose the API to 3rd parties (outside your organization).

Tal
  • 7,827
  • 6
  • 38
  • 61
  • "And is recommended only if you expose the API to 3rd parties" => actually I'm building a public social network, so is it still enough to keep the SecureSocial solution working on cookies, rather than Oauth? Thanks a lot :) – Mik378 Mar 12 '14 at 07:21
  • In that case, OAuth is better as developers can use built in OAuth libs to easily integrate with your API. – Tal Mar 12 '14 at 14:06
  • I've got my official Javascript client and my backend as a set of Rest APIs. Is the Javascript client considered as 3rd party ? I think yes so go Oauth :) Right? – Mik378 Mar 12 '14 at 15:20
  • sure, javascript can be a client of course, but by 3rd party I meant someone external to your organization. Anyhow, enjoy your OAuth experience! – Tal Mar 13 '14 at 19:54