1

I understand that the idea of a session was conceived originally to improve user experience with Web applications. I also understand that session implementation can introduce attack vectors if not done securely i.e., if session ID can be spoofed because it replaces authentication.

Does having no session ID introduce any attack vectors, for example for an app that requires authentication on every request?

schroeder
  • 129,372
  • 55
  • 299
  • 340
postoronnim
  • 446
  • 4
  • 12
  • "an app that requires authentication on every request": in what form? E.g. sending username/password with every request, or something else, e.g. sending an API key? –  Sep 14 '23 at 17:50
  • @Spyros It's basic http auth on every request, over TLS. – postoronnim Sep 14 '23 at 18:10

1 Answers1

1

Authorizing requests (i.e. that they come from an authorized, thus authenticated, entity) can be done in many ways.

One way is using the http basic authentication and its improvement, digest authentication. Http basic auth is what you prefer to use.

Another would be to use mTLS between a client (application, not host) and a server.

A third way would be to provide an access token (or API key) to the authenticated entity (or use a session token1) that will be provided with every subsequent request. The access token can be opaque or structured (e.g. JWT) and can be exchanged between the client and the server in a header (e.g. Authorization or Cookie), the query string of the request URL or the request body (as a value to a pre-determined key).

Each has its pluses and minuses but, all other things being equal security-wise, replacing an access/session token (or API key) with http basic auth makes little difference. There are, however, reasons (see, for example, here and here) that have led us to move away from http basic auth, of which I'd like to mention the following:

  • it requires validating the credentials on every request, which can be expensive (CPU-wise) in high traffic sites/APIs

  • it's more expensive to keep a session like this, should you need it, because it requires two steps to restore the session server-side (validate credentials + lookup of session data). On the other hand, when using a session or access token you just need one (lookup of session data)

  • in the case of browsers, there are security issues similar to using cookies (e.g. CSRF), due to caching of the credentials at the browser side2

Finally, to answer your question:

[...] does having no session ID introduce any attack vectors [...]

No, as long as you follow best practices on security for the specific authentication method.

1 Session tokens usually refer to stateful conversations (e.g. browser-API interaction), whereas access tokens/API keys usually refer to stateless communication (e.g. software agent-API interaction). See here for a short description of session and access tokens. Also, see here for a reference to the difference between an access token and an API key

2 From here: "Because the BA field has to be sent in the header of each HTTP request, the web browser needs to cache credentials [...]"