What is the principle of operation when authentication JWT?

Warning: count(): Parameter must be an array or an object that implements Countable in /home/styllloz/public_html/qa-theme/donut-theme/qa-donut-layer.php on line 274
0 like 0 dislike
Good evening, trying to implement a web service of rest which should provide work movie posters.
Task rest service to give all the movies, delete, change the description of the film.
Sekyuriti - must have two roles admin and user, delete, and change description may only admin. To do the authentication with jwt.
Found articles about this spring sekyuriti + rest + jwt but at the moment I just started to learn sprin...
As I'm trying to do, WildFly server + mongoDB + REST jersey + servlets, and can't understand how I screwed jwt, namely to understand the logic during untypical and after it!!
With the rest some how figured out, but with no sekyuriti, the Issue of which principle of operation between a client and a web server at auntefication jwt?
For example, the user entered login and password pressed the form to enter, it flew to the specified url there is a server, the user token and where it is stored in the browser???? in cookies or where?
What is the principle of operation of the user and the server auntefication and what after auntefication?
The Council, an explanation of an example is welcomed.Thank you.
by | 23 views

1 Answer

0 like 0 dislike
jwt is primarily used in microservice architectures, when the final client request will be handled by one of several servers.

Classically this architecture used the OAuth mechanisms. that when servicing each client request implemented request to the server OAuth "client token AAA requests for actions BBB"

It is clear that the bottleneck becomes the server's OAuth which should withstand the "storm" of requests under load. The second bottleneck of this architecture is the latency of the response to the query in the query at least 1 will fail the authorization request.

If we are talking about the "classic" monolith, for example using old cookie requires the server to keep in memory all open user sessions - too much stress on the service authorization.

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 available actions, in addition provides information about the lifetime of the token. Definitely at the end of the token the digital signature. It actually checks the "validity" of the token.

The algorithm is simple:
1. to run the authorization - to answer 2 of the access token, refresh.
2. turn to microservices using access token.
3. if you must use the refresh token updated access token.
4. and when refresh token has expired - the ongoing re-authorization.

Where to store JWT token anywhere. it all depends on the tools and implementation. For example, you can implement storing token in LocalStorage and probrasyvanie it during each request, in the form of headers and. If the same domain - the token can be stored in a cookie, etc.

What can be stored in the payload? The developer should decide for themselves how much information to publish this token, in addition it's worth noting that information from the token can be read - it's just base64 encoded JSON string...

Related questions

0 like 0 dislike
3 answers
0 like 0 dislike
2 answers
0 like 0 dislike
2 answers
110,608 questions
257,187 answers
40,796 users