In a previous article, I talked about the basics of JWT
. If on your fingers, then this is just the key with which we open the door to private resources. But what if this key is stolen (more precisely, they will make a duplicate). Then someone else will be able to log into the server under your name, and we may not even know about it. We do not want to allow such a scenario. But what to do?
I suggest readers, before moving on independently, to think about what we can do with security.
Here are a few approaches that can improve security. You can write in the comments what other approaches exist - I will add them.
https
http
SSL
TLS
IP
payload
IP
IP
IP
RS256
RS256
JWT
takes advantage of the JWS
(Signature) and JWE
(Encrypting) coding JWE
. The signature does not allow someone to fake a token without information about the secret key, and encoding protects against reading data by third parties.
Let's see how they can help us to authenticate and authorize the user on the site.
Authentication (English authentication; from the Greek. Αὐθεντικός [authentikos] - real, genuine; from αὐθέντης [authentes] - the author) - authentication procedure. In our case, we check the login + password for a match with the entry in the database of user data.
Authorization (English authorization - permission, authorization) - providing the user with the right to perform certain actions; and also the process of checking (confirming) these rights when trying to perform these actions.
In other words, authentication verifies the legality of the user, and then, if all is well, the user becomes authorized, that is, he can perform permitted actions with the database. Usually, these two processes are combined, and therefore there is a well-known confusion.
IP
The main use case is this: as soon as the old JWT
expires, we can no longer receive private data with it, then we send RT
and we receive a new pair of JWT+RT
. With the new JWT
we can again turn to private resources. Of course, a refresh token can also go bad, but this will not happen soon, because he lives much longer than his brother.
The key idea of token separation is that, on the one hand , authorization tokens allow us to easily verify a user without the participation of an authorization server, simply by comparing signatures.
const validateToken = token => { const [ header, payload, signature ] = token.split('.'); return signature === HS256(`${header}.${payload}`, SECRET_KEY); }
On the other hand , we have a
that allows us to update the access token without entering a password from the user, but in this case, we still need to perform an expensive operation of accessing the authorization server.
Thanks to this approach, we reduce the time delay for accessing the latency
server, and the server logic itself becomes much simpler. And from a security point of view, if an access token was stolen from us, only a limited time will be able to use it - no more than its lifetime. For an attacker to be able to use longer, he will also need to steal a refresh, but then the real user will find out that he was hacked because he will be thrown out of the system. And once such a user logs in again, he will receive an updated pair of JWT+RT
, and the stolen ones will turn into a pumpkin.