What is the working principle of JWT authentication?

Question

Java

Good evening, I'm trying to implement a rest web service that should ensure the work of a movie poster.
The tasks of the rest service are to give all the films, delete, change the description of the film.
Security - there must be two roles admin and user, only the admin can delete and change the description. Authenticate using jwt.
I found articles about this spring security + rest + jwt but at the moment I just started to study spring ...
How am I trying to do, WildFly server, + mongoDB + REST on jersey + servlets, and I can’t figure out how to fasten jwt, . Namely, to understand the logic of work during and after auntification !!
I somehow figured out the rest, but not with the security. The question is, what is the principle of operation between the client and the web server during jwt authentication?
For example, the user entered a username and password, clicked on the login form, it flew to the specified url there is a server token for the user and where is it stored in the browser ???? in cookies or where?
What is the principle of operation of the user and the server during auntification and what is after auntification?
Advice, explanation, example is welcome. Thank you.

Answer 1

jwt is primarily used in microservice architectures where the final client request will be processed by one of several servers.
Classically, this architecture used OAuth mechanisms. which, when servicing each client request, made a request to the OAuth server - "a client with an AAA token requests a BBB action"
It is clear that the bottleneck is the OAuth server - which must withstand the "storm" of requests under load. The second bottleneck of this architecture is the increase in the response time to the request - at least 1 authorization request will be executed within the request.
If we are talking about a "classic" monolith, then for example, the use of old cookies requires the server to keep in memory all open user sessions - also a big load on the authorization service.
JWT solves these problems in the following way: the access token immediately contains the necessary information: for example, about the Roles of the current user, or about the actions available to him, in addition, it provides information about the lifetime of this token. A digital signature is required at the end of the token. It actually checks the "validity" of the token.
The algorithm is simple:
1. Authorize - get a response 2 access, refresh tokens.
2. We access microservices using an access token.
3. if necessary, update the access token using the refresh token.
4. when the refresh token has also expired, we re-authorize.
Where to store the JWT token - anywhere. it all depends on the tools and implementation. For example, you can implement storing the token in LocalStorage, and forwarding it during each request in the form of a header. If the same domain - then the token can be stored in a cookie, etc.
What to store as a payload? The developer himself must decide for himself how much information to publish in such a token, in addition, it should be borne in mind that information from the token can be read - it's just a base64 encoded JSON string...