SPA and REST API - how to correctly build authentication?

Question

User identification

Now I am making a REST API that will be used in SPA and mobile applications.
I seem to know the theory about different authentication methods, I read a lot of articles, looked at examples, but I still don’t understand how to do it conveniently and safely.
On the one hand, it seems obvious: token-based authentication - OAuth or something like that. You can experiment with JWT. But the token can be stolen, so it must be with a limited lifetime.
On the other hand, if the user has not logged into the application for two days, and his token is rotten, then he should not be kicked out of the application. For the user, everything should be as convenient as possible.
It seems there is such a thing as a refresh token, but how to use it correctly?
Does it make sense in a completely stateless API, or is it more convenient to store sessions?
I would be very grateful for articles that describe in detail these problems and how to solve them, best practices in this area, or maybe some ready-made tools ...

Answer 1

I think jwt authentication is enough.
Here it is written well about all the tokens and how they work.
https://auth0.com/blog/refresh-tokens-what-are-the...

Answer 2

We make two authentication methods: Resource Owner Password Credentials Grant and Refresh token grant .
SPA sends the user's login/password to the first endpoint. In response, we get access_token (for example, JWT), refresh_token and expires_in . We save all this stuff somewhere, for example, in Local Storage. It is better to set the lifetime of a JWT token to a small one (for example, 1 hour), because it cannot be revoked. Next, the SPA checks the lifetime of the expires_in token from Local Storage with each request to the API, and when it expires, sends a request to refresh the token ( refresh_token ). All this is transparent to the user.
Stateless, in my opinion, is both simpler and more versatile. If you then make, for example, a mobile application, the API will not have to be rewritten.
The whole point of JWT is essentially only that you don’t need to pull the database with every request to the API. You will have to do this, for example, only once an hour when refreshing the token. There are no other significant advantages over traditional tokens stored in the database.
I advise you to smoke the official RFC on oAuth2, and not any blog posts a la "OAuth2 in simple words". Went through it myself. RFC is the most understandable and intelligible source of knowledge.

Answer 3

Here is a proven and working method. No sessions!
Only checking the "fading" of the token and its renewal (exchange!) in the "transparent" mode.

Answer 4

And what's wrong with simple basic authorization

Answer 5

Basic authorization is enough

Answer 6

someday I will definitely understand why the "usual" approach with cookies and sessions is bad..

Answer 7

I meditated on the topic of JWT for a long time and realized that it would be impossible to refuse sessions.
Plus, there are still a lot of pitfalls with refresh tokens, which are extremely difficult to get around.
cryto.net/~joepie91/blog/attachments/jwt-flowchart.png