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?
Increase security
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.
- Using the
https protocol, which protects the data channel over the Internet. In fact, this is a wrapper over http , which imposes additional cryptographic protocols - SSL and TLS - Adding
IP information to payload . Then the token from other IP will not pass the verification. But IP can be faked, and what to do with dynamic IP addresses or when a user connects from a phone in a cafe or metro. Therefore, we will not use this approach. - Use
RS256 . This ensures the security of the private key itself. But with tokens, everything remains absolutely as it was. We need RS256 when we are afraid to pass the secret key to other servers, which may be unreliable. We give them only a token authentication tool, which is absolutely useless for an attacker. - Use short-lived tokens. But then the user will have to re-login every time he expires. The user will get tired of this sooner or later and he will leave our resource.
- But what if you use short-lived tokens anyway, but give it another token, the purpose of which is only to get a new short-lived token without a new authorization? Such a token is called a Refresh token and it will be possible to use it only once. This will be my article.
Recall What JWT Is
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.
Types of Tokens
- Access Tokens (JWTs) are tokens that can be used to access protected resources. They are short-lived , but reusable . They may contain additional information, such as lifetime, or
IP address from where the request is coming from. It all depends on the desire of the developer. - Refresh Token (RT) - these tokens perform only one specific task - obtaining a new access token. And this time you can’t do without an authorization server. They are long-lived , but disposable .
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
Finally
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.
useful links
- Why do I need Refresh Token if I have Access Token?
- Refresh Tokens: When to Use Them and How They Interact with JWTs
- More OAuth 2.0 Surprises: The Refresh Token