3 votes

Browser Session vs JWT tokens for authentication system for an app?

Posted by noble_pleb
Tags: web, websites, apps

I'm working on an app idea, it's going to be "API first" in design which means there is a clear separation between the backend and frontend. Former will be accessible through a REST API and the latter can be simple HTML without me having to delve too much on it. The idea is that the end users or clients will write their own front-end interacting with this REST API in future.

Firstly, I want to know where to start. Writing a REST API seems quite easy and simple for me as a backend engineer but I've never implemented a "pure API" app in practice. Do you just validate the headers, do the crunching and return back a JSON response? What all must you take care of here?

Finally, authentication and session handling is something very important here, isn't it? If I make use of session feature in the REST API (like PHP sessions or Django sessions, for eg), authentication will be pretty easier. I don't have to worry about encryption as SSL/TLS would be already doing that for me through the browser. But then what is the downside of this method? Why do so many people use JWT tokens then?

Coming to JWT tokens, is that the only way of encrypting/validating REST APIs, or are there others? My biggest concern here is scaling and performance. I'm willing to implement the most efficient path here, the one that gives the most performance using least resources.

1 comment

  1. DataWraith
    Link
    Writing a REST API seems to not be that hard, but the devil is in the details. It is easy to make an API too tightly coupled to your own frontend so that it becomes harder for others to use the...

    Writing a REST API seems to not be that hard, but the devil is in the details.

    • It is easy to make an API too tightly coupled to your own frontend so that it becomes harder for others to use the API, so keep that in mind.
    • Browser sessions usually require cookie storage, which is inconvenient to deal with when you're writing an API client or just want to test things with curl.
    • Because of that, instead of browser sessions, APIs usually use Bearer Tokens given in the Authorization header.
    • Bearer Tokens can be JWTs, but you can also use custom ones (e.g. just generate a random Base64 string per user and store it in your database)
    • If the API is exposed to the public, you'll want some sort of rate limiting in place (per user and per IP)
    • Think about how you want to paginate results if you don't want to serve everything in one request (e.g. cursor-based pagination)
    • I personally haven't used it, but tools like PostgREST can make serving an API simpler if you know your way around Postgres
    • JWTs are something of a double-edged sword. There were security vulnerabilities in several popular libraries, and the advantage of using a JWT over a random or HMAC-signed token really only comes into play when you have multiple servers or microservices: One server (e.g. a Login microservice or external provider like Auth0) can sign a request, and if you pass that to another server, it can verify that the first server authorized the request. The advantage is that the user password or API-Key is only stored in that one location and does not have to be distributed to all API servers, but that only comes into play if you have multiple servers.
    4 votes