I'm trying to build an application by creating an RESTful API(Koa.js) to communicate with clients(Web with React and Mobile with Ionic). But I'm facing issues when dealing with authentication.

So my question is: How should I implement authentication in this scenario? It is ok to use just stateless token based auth or should I also implement session based auth for web clients?

Thanks in advance.


3 Answers 3


tl;dr: In your particular case, theres no reason not to use token based authentication. Your OAuth provider will probably provide you with JWTs anyway. You need to make sure your tokens are appropriately protected (use TLS, pick an appropriate lifetime).

Its a bit of a myth that theres anything inherently wrong with sessions for maintaining state. Its true that HTTP is stateless, and REST (since it closely mirrors the underlying protocol) works best when its also stateless.

An entirely stateless application, however, is extremely limited. For anything non trivial, you need to store some state, somewhere. You can either rely on the client to store this state (in the form of cookies, or some other local storage), or ask the server to store it in some form. The two main considerations you need to make are:

  • How much state you need to store
  • How sensitive is the data

If you have a lot of application state, storing it in the client passing it along with every request will increase latency for your application, and if your data is very sensitive, you need to ensure that you have provided suitable protection (encryption) or you dont pass the state to the client at all.

In the case of OAuth2, the tokens passed back to the client are effectively the state (representing authentication). These can either be in the form of JWTs (where the information is contained in the token itself) or some form of reference token, that the server can use to look up the pertinent information.


It is ok to use just stateless token based auth...

Yes it's. If we give the due importance to the stateless constraint and we consider its benefits, we find token based protocols to make a big deal. Overall when It comes to distributed solutions.

or should I also implement session based auth for web clients?

To my experience, balancing stateful and stateless sessions within the same Web API is hard and eventually counterproductive because at some point stateful and stateless APIs will need something from one another and we will find us trying to conciliate two different sessions at the same time on both sides of the system (client and server).

How should I implement authentication in this scenario?

Be consistent, treat all clients equally, so that you can reuse the same solution no matter where the requests came from. Ultimately, they all are web clients and they should be playing with the same rules. The HTTP' ones.

Since we are speaking about web APIs, consider the stateless solution (tokens and sessions on the client-side) since it's the one that fits best with the web. The more web compliant we are the more advantages we take from its architecture.


When implementing REST, one of the best practices is to avoid state in the webserver. Sessions tend to be implemented in the webserver by default (there are ways to avoid storing session state in the webserver, of course). Because JWT tokens do not need any state for authentication, they do make the most sense if you are going with REST.

As you are building a new application you should be able to work with token-based authentication.

  • Why is this downvoted? Commented May 25, 2018 at 8:35
  • I downvoted as well. REST pretends to be stateless. To a certain extend, JWT is a kind of state, not even mentioning underlying database. BTW, REST is shortage for the Representational State Transfer, so it proves that state is still there. I would say, that REST is just a widely spread fashion, which is quite good for simple enough read/write operations, extended by advanced filtering, sorting and this kind of stuff. It also promotes a good segregation of business domain, but nothing - nothing - more. All beyond that is a marketing and gonna die once like XML did.
    – Zazaeil
    Commented Dec 20, 2018 at 12:39
  • @SerejaBogolubov: REST pretending to be stateless is an interesting view. I can follow that for part of the way. I'll update my answer to reflect that. Commented Dec 24, 2018 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.