How to properly organize the registration and authorization of site users (Java)?

Question

Java

Good day!
In the process of creating the site, there was a need for registration / authorization of users.
Used technologies:

• For the server side I use Java, in particular Servlets.
  
• User data and other mutable data is stored in PostgreSQL.
  
• To access PostgreSQL from java I use (jdbc:postgresql).
  
• I use Tomcat as a container for Servlets.
  
• Before Tomcat'om there is nginx for return of statics. (css/js/html/img)
  
• To transfer data between the browser and the server, without refreshing the page, I use AJAX (&& json).
  

Required scenario:

1. The user gets to the registration page, creates an account. The data is sent to the server and stored in the database. The password is pre-salted and hashed. (The hashing algorithm and the order of adding the salt have not yet been chosen, this is not the main question, but I will be glad to have an authoritative opinion, knowledgeable people)
   
2. After registration, when accessing certain pages (servlets), the user goes through the authorization procedure. Enter username/password. Login and password are sent to the server in a post request. There, a hash is calculated from the password and compared with what is in the database. If the hashes match, the user is considered authorized and receives something that he will later present when accessing pages that require authorization. This something is also entered into the database.
   
3. And actually access to the pages requiring authorization. The user sends, this is the "something" received during registration and receives a page in response. (In fact, this will be the result of the work of the servlet (data), which is turned into a page on the browser side using js).
   

Question 1. Did I understand the User Registration and Authorization process correctly?
Question 2. "Something" issued during authorization is called a "token". What is a token? (a random string that is essentially an identifier? If so, what length should it be, should it be encrypted and where should it be stored on the client side?)
Question 3. Heard about OAuth and long and short lived tokens (refresh token and access token ). As I understand it, the main concept is to limit the attacker's access time when stealing tokens. Such a scheme seems to be more reliable, but again the same questions and even new ones arise. What is a token, what length of a token is considered secure, whether it needs to be encrypted and how to generate it. And also where and how to store on the browser side.
In some articles, when updating any of the tokens, it is proposed to send a new pair of tokens (instead of one that is being updated), in this regard, the question arises of how the situation is resolved when the User requested a refresh token update and at that moment lost connection (could not receive a new pair ). After the connection is restored, the user tries to request refresh tokens again (using the old refresh token). However, a new refresh token is already stored on the server, the one that did not reach the user. And all that remains for the user is re-authorization (login / password). Is it worth worrying about in real life because of such a situation? or is it a tolerable and very rare glitch that won't force users to re-enter their password all the time?
Question 4.Is OAuth secure enough or should I look for something else? jwt?

Answer 1

Basically everything is correct. I would slightly tweak the following points:
>> The user sends, this is "something" received during registration and in response receives a page
Not a user, but a client (the user is sitting at the computer). But the client is not your program, but basically a browser (curl is also a client) and your program can have access to some cookies at most, and even then not to all (how the server sets the cookie, see httponly cookie). The server checks the token and matches the application context (php / java) with the user parameters (_GET / _POST / _SESSION), so the backend code, as a rule, cannot influence the user context in any way, only if it does not contain errors for performing critical operations. (Naturally, you need to understand the server architecture, because at the filter level, and they are in tomcat / IIS, you can do a lot of bad things even before processing the request under the user).
>> What is a token? (a random string, which is essentially an identifier? If so, what length should it be, should it be encrypted and where should it be stored on the client side?
A token is a unique session identifier in the format of a string. You can insert JSON.stringify() into it, but the browser will still identify it as a string. He doesn't care about symbols. Issued per session on one client. Those. if you connect / log in with different browsers under the same user login, they will have differenttokens. However, if you can technically steal a token from one browser and stick it in another, then you will actually work under the same session in different browsers and you won’t have to authenticate in the second browser (Sometimes this can be used for tests). It is for this reason that tokens should be buried to the maximum, i.e. send them in headers and in the HTTPS protocol. Only this does not apply to the Kerberos protocol, where authentication is performed by a different mechanism and taking possession of the cookie will not work (a very complex mechanism, used in corporate networks, not on the Internet).
where to store on the client side - For cookies, the browser itself stores them and appends them to the headers when executing requests, so this is done transparently. Put fiddler , everything is visible there.
whether it needs to be encrypted - Usually not.
>> Heard about OAuth and long and short lived OAuth tokens
are used when you want to reach a large number of users, assuming they have social media accounts, ie. this protocol simplifies both registration and authentication, but is more difficult to configure than form-based. there is one subtlety here - a user account in your program will still need to be created and associated with a profile account in a social network (I won’t tell you more now, I’ve been studying for a long time)
Now what is the connection between the token and OAuth and remember that OAuth is an authentication protocol, and after authentication you need to (drum roll ...) tadam - set a session token !!! Those. with OAuth you onlyyou check the validity of the user, then your program finds out which account on your site he is associated with and sets the token/cookie so that each request from the user of accounts from the social network is not authenticated. Well, imagine that even on CSS and IMG it will be necessary to require confirmation? (unless NGINX is configured to serve static, as you indicated above).
>> If so, how long should it be
Look at the formats and sizes of tokens issued by social networks? Yes, take the same toster.ru, right now: you come up with a session token yourself. Though sid
. The token string format is undefined. The main thing is not to accidentally issue a similar token to another user when identifying a user, otherwise it will turn out that two users are identified by the server as the one who logged in first. So one of the problems of the server is to ensure the uniqueness of session tokens, and this is an important section of security. It is quite possible to look for ways to compromise the issuance of the "necessary" tokens, and then the site's security is under great threat.
>> Is the level of OAuth security sufficient or should I look for something else? jwt?
Since OAuth also starts with a hanger, i.e. with form-based authentication in the social network, then the main thing is to ensure a sufficient level of secrecy - HTTPS and everything will be fine.

Answer 2

1. True (but these are approaches from the 90s)
2. Why encrypt a random string? encrypt data, the token can either have some data (which is then necessarily encrypted), or not have any data, then it is not necessary to encrypt, and such "tokens" are usually transferred to users in the form of sessions.
3. encrypted tokens, usually contain everything you need, the point is that after receiving the token, you decrypt it and receive all the necessary data for authorization from the token itself, and not look for something in the database.
the browser can save data through cookies, as well as in localStorage (well, there are still exotic options)
4. a little chaotic and confused, OAuth - just defines a set of rules for which secure authorization is carried out, jwt - a data transfer format encrypted with json (you can use both different formats for data transfer and different rules for authorization).