What is the name of such authentication and how to choose the right method?

Question

PHP

I read several articles on authentication methods. There is a little mess in my head and a few questions remain.
Sessions.
A session is a way to save state on the server between user requests. A session is created on the server (usually a file or a record in a database or in memory). This session has an id that is returned to the user on the client and stored in a cookie. On further requests to the server, the client passes the cookie and the server knows who is accessing it.
You can add or remove data to a session. The session can also be deleted on the server and thus log out the user.
The disadvantages of this implementation include some problems with cookies in mobile applications. What kind of problems do not write. Still sessions by default are created on each new client. That is, each time you visit the site, a file is created on your hard drive.

Tokens.
For example JWT. On the server, a special library encrypts user data and receives a token. The resulting token is sent to the user and stored somewhere, usually in localStorage. On further requests to the server, the user sends this token to the server, where it is decrypted. Here, the difference from the session is that the data in the existing token cannot be added / deleted, a new token must be issued.
The downsides to this approach are:
1) It is not possible to invalidate a specific token. That is, log out the user from the server.
2) You cannot edit data that is encrypted in a token.
3) There is no easy way to extend the lifetime of a token. It is either eternal or for a specific time, for example, for an hour and is not automatically renewed. It is possible to renew the token, but it will no longer be an extension, but the release of a new token.

Storage method:
Regardless of which method is chosen, we can store session_id and token both in cookies and in localStorage. Both methods have their advantages and disadvantages.
Cookies:
1) Automatically sent to the server
2) Have a length limit (but it doesn't matter in this case)
3) You must use a CSRF token.
4) No risk of stealing cookies through XSS.
5) Cookies are available on the server before the client is loaded. That is, for example, if we have a SPA site, then the data can be received already at the first page load.

Tokens:
1) No need to think about CSRF attacks.
2) You need to think about XSS so that the token is not stolen.
3) Data can only be received after the client is loaded.

Tell me, please, what are the disadvantages of cookies in mobile applications, and if there are problems with cookies, then why not store the session_id somewhere else? What other pros/cons do both implementations have?

UPD: In general, analyzing the pros and cons, I see no reason to use tokens, there are only cons.
And in my project I use the following scheme:
When authorizing, I generate a hash, which I save to the authorized user in the database. I send the hash to the client, save it in LS. I do not store any state (data about the user) on the server. With each call, I send this hash from the client and on the server I get information about the user from the database using the received hash.
The only negative for me is that the hash is not available when I first access the server (I have an SSR application). But this can be fixed by moving the hash storage from localStorage to cookies. In general, the method that I use differs from sessions in that no storage is created on the server (session file or session record in the database).
What is the name of the method I am using? And why is it worse than sessions, if you do not need to save data in the session?

Answer 1

It all depends on who and how will contact the backend.
If this is another server, mobile application or SPA, then it is better to use tokens - JWT is the most common option.
In the case of a regular site or SPA, it is possible to use sessions.
If we use regular static pages + http api, then the session is quite a normal option, including for an application of the web-view type.
If we use SPA with REST api / Graphql then tokens are more convenient.
As for where to store the user id in the token, the JWT itself has a header for this. Generally Jwt is 2 json + hash/key stuck together via base64.
The first json is a service one, it contains the algorithm and key type, the second one is customizable and can contain anything, although for some moments, for example, token id (jti) or session id (sid), there are predefined headers. Full list of them here
. In your case there are 2 options
1 -
API and SPA session access requires a session for protected methods, authorization provides this session. Authorization - can be performed as a regular static html with a form or a separate SPA.
2 - access by token
In this case, Authorization is implemented as an api on the server side, and as a token
+ form + authorization logic on the client side (Vue). If there is a token, then there is access, if not, then access is only to the registration and authorization methods.
In order not to burn the code of that part of the application where there is logic and the front of the closed part, you can use code-splitting - the authorization form is loaded first and the rest is loaded when it is needed.
There are really even more perverted options like SPA with SSR on the same Nuxt / Next / Express where the user has a token and the back on Go / JAVA / PHP already has an application token + user token.
Sometimes it is worth using OAuth2.0 and LDAP which are also quite interesting.
The first one is good for all occasions, but only if you use a bunch of related applications / microservices and the second one is heaven for business users with Windows for some boxed CMS.

Answer 2

In general, the method that I use differs from sessions in that no storage is created on the server (session file or session record in the database).

In fact, you store a record in the database with the session key, that is, you do not copy the data to a new storage, but bind the existing data to the session, essentially mixing entities (IMHO). Plus, you lose the ability to store states on the server when they are needed. Plus, you pull the user table every time you need to log in / log out a user, instead of deleting / creating an entry with a link to users. As a custom solution of the norms, but in general it is too ... specific.