I am doing a hypothetical web just for learn some security tips and the first problem I've found is the login, I've read like 40 articles, a lot of questions here on stackoverflow and I still don't know which method is the best one (this is a non-real case, so we can assume we need a very high security)

most webs I've developed I use a expirable access token that I need to send on every call to the API via query param or via Authorization header, then I store the token on the local storage

I've read some articles that claims that way is unsecure and the best way is with cookies, I've read also that the best way is with sessions

Any hint? I'm a bit confused about which way is the best one to secure first the authentication and then the store of the access token to make the authorization

  • 1
    You are conflating "web app" with "web API". Which one do you want to authorize for?
    – MechMK1
    Dec 2 '19 at 9:09
  • thanks, you're right, I meant web API Dec 2 '19 at 9:10

Stateless Authentication

Stateless Authentication, such as can be implemented with JWT, has become very popular in recent times. Your question mentions session identifiers, which are a form of stateful authentication. Basically, you authenticate somehow (by showing credentials, possibly with a second factor, etc.), and in exchange receive a session identifier. The server stores this session (e.g. creates a "state") and compares the session identifier you send to the server's active session list.

Stateless Authentication goes down a different path. Basically, the server also sends you a token, which you hold onto, and send back with every request. To the client, there is no noticeable difference in procedure: Authenticate, receive something, send this thing back.

However, where Stateless Authentication differs is how the server validates it. For example, when Alice authenticates with her password and 2FA code, the server writes User Alice (ID: 1337) has authenticated at UNIX time 1575281516. and then signs that piece. When Alice sends that token back, the server checks if the signature is valid, and if the time of issue is not too long ago.

How is this any different?

On the surface, Stateful and Stateless Authentication seem identical, with only minute differences. But the true difference is at scale. Imagine a web-application that issues millions of users millions of different sessions. The server has to hang onto all of them.

With Stateless Authentication, the server can issue a token and immediately forget about it. There is, as the name imples, no "state" to hold onto. A token is able to validate itself. This can be quite the performance boost.

What are the problems with Stateless Authentication?

Auth0 has an article of Common Threats and How To Prevent Them, which explains issues you may encounter with Stateless Authentication. As with all technologies, it takes some time to adapt and fully understand how it works and what it can do for you.

Is Stateless Authentication better than Stateful Authentication?

Not necessarily. It's another way of doing things, with its own up- and downsides.

  • Thanks for the answer, this is going to help me to decide the authentication I use Dec 3 '19 at 10:52

"Best way" is almost always subjective in questions like these. There are some very good ways, and you should consider them all and how they fit your hypothetical scenario in order to select the "best" one.

That said, one method that I would rank highly would be using mutually authenticated certificates, aka "Client Certificate" authentication. TLS can require that both the server AND the client use certificates to establish the connection. In order to connect to your service, the clients would need to prove themselves to a certificate authority and request a signed certificate, which they would send as a part of the TLS handshake process.

You could also require the certificate provider to issue the client certificates with a suitably short lifetime to make sure that the clients are authenticating to the cert provider on a regular basis.

Also note that authenticate and authorize are two very different activities. Certificates are great for authentication, but you should probably be looking at a different mechanism for authorization.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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