Is it an implementation of a stateful mechanism for Rest API authentication?

Question

In many articles about Rest API's best practices, it is recommended to not depend upon sessions on server side since it leads to a stateful mechanism.

I currently use Play 2.2 framework, with a mechanism that store the data about logged in user in the Play cache (temporary persistent so).

When the user wants to authenticate, it calls a dedicated API that grabs its credentials and if valid, server generates a cookie that will be sent to him. This cookie contains a reference id of the user's data in the Play's cache.

Then, each time a user calls an API requiring user authentication, server grabs the user cookie (if any), asks for the cache and checks in there whether user is well already authenticated regarding the validation duration.

Here a little sample:

def myApi = userAuthenticatorRequest.securedAction {    //user has to be already logged in
    implicit request =>
      //do something
  }

Should I leave from this solution in order to be compliant with best practices, or should I keep it? Is it really considered as a stateful mechanism? If I understand, this is stateful since a call to a secured API required actually two calls:

• authentication api
• secured api

while a stateless would authenticate user directly in the secured api, and thus would be totally independent of any context. Of course, user would have to sent each time its credentials (or API key)

Answer 1

If I understand, this is stateful since a call to a secured API required actually two calls

This is stateful because the information „user X has been authenticated at time T“ is maintained on the server side.

Of course, user would have to sent each time its credentials (or API key)

A user can also sign each request to attest her identity, thus proving the server she can access some private key.