Return to Answer

A general rule of thumb is "don't roll your own security".

Firstly answering the main question, whether the security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way or not, it is. Well, it depends on the implementation though. Having a long-lived refresh token may seem to be a good idea, but is not. To understand this better, let’s consider a scenario where an attacker gets hold of a refresh token. Now the attacker can keep accessing that user account till that particular refresh token is not invalidated in your database.

Going through ITEF RFC 6749 and ITEF RFC 6819, you’ll understand why refresh token should be used only once and why rotation of refresh token is required. Well, good news, you don’t really need to go through the whole doc. Here is an important quote from this documentation:

“The authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.”

Well, it’s tricky as well as complex to have a correct working solution where we can assure that refresh tokens are used at most once and are rotated correctly. The scenario where refresh token might get lost during the transit is not easy to handle either. We at SuperTokens have found a perfect solution that doesn't only do the rotate the refresh token on each use but also helps to identify the token theft scenario, i.e. if someone has stolen your refresh token.

Well, of course, the solution also takes care of preventing various session related attacks such as XSS, CSRF.

A general rule of thumb is "don't roll your own security".

Firstly answering the main question, whether the security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way or not, it is. Well, it depends on the implementation though. Having a long-lived refresh token may seem to be a good idea, but is not. To understand this better, let’s consider a scenario where an attacker gets hold of a refresh token. Now the attacker can keep accessing that user account till that particular refresh token is not invalidated in your database.

Going through ITEF RFC 6749 and ITEF RFC 6819, you’ll understand why refresh token should be used only once and why rotation of refresh token is required. Well, good news, you don’t really need to go through the whole doc. Here is an important quote from this documentation:

“The authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.”

Well, it’s tricky as well as complex to have a correct working solution where we can assure that refresh tokens are used at most once and are rotated correctly. The scenario where refresh token might get lost during the transit is not easy to handle either. We at SuperTokens have found a perfect solution that doesn't only do the rotate the refresh token on each use but also helps to identify the token theft scenario, i.e. if someone has stolen your refresh token.

Well, of course, the solution also takes care of preventing various session related attacks such as XSS, CSRF.

A general rule of thumb is "don't roll your own security".

Firstly answering the main question, whether the security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way or not, it is. Well, it depends on the implementation though. Having a long-lived refresh token may seem to be a good idea, but is not. To understand this better, let’s consider a scenario where an attacker gets hold of a refresh token. Now the attacker can keep accessing that user account till that particular refresh token is not invalidated in your database.

Going through ITEF RFC 6749 and ITEF RFC 6819, you’ll understand why refresh token should be used only once and why rotation of refresh token is required. Well, good news, you don’t really need to go through the whole doc. Here is an important quote from this documentation:

“The authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.”

We at SuperTokens are working on a product for session management right now which can easily solve the above problem!

Well, it’s tricky as well as complex to have a correct working solution where we can assure that refresh tokens are used at most once and are rotated correctly. The scenario where refresh token might get lost during the transit is not easy to handle either. We at SuperTokens have found a perfect solution that doesn't only do the rotate the refresh token on each use but also helps to identify the token theft scenario, i.e. if someone has stolen your refresh token.

Well, of course, the solution also takes care of preventing various session related attacks such as XSS, CSRF. If you want to read more about this solution, you can head over to Supertokens.

A general rule of thumb is "don't roll your own security".

Firstly answering the main question, whether the security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way or not, it is. Well, it depends on the implementation though. Having a long-lived refresh token may seem to be a good idea, but is not. To understand this better, let’s consider a scenario where an attacker gets hold of a refresh token. Now the attacker can keep accessing that user account till that particular refresh token is not invalidated in your database.

Going through ITEF RFC 6749 and ITEF RFC 6819, you’ll understand why refresh token should be used only once and why rotation of refresh token is required. Well, good news, you don’t really need to go through the whole doc. Here is an important quote from this documentation:

“The authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.”

Well, it’s tricky as well as complex to have a correct working solution where we can assure that refresh tokens are used at most once and are rotated correctly. The scenario where refresh token might get lost during the transit is not easy to handle either. We at SuperTokens have found a perfect solution that doesn't only do the rotate the refresh token on each use but also helps to identify the token theft scenario, i.e. if someone has stolen your refresh token.

Well, of course, the solution also takes care of preventing various session related attacks such as XSS, CSRF.

A general rule of thumb is "don't roll your own security".

Firstly answering the main question, whether the security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way or not, it is. Well, it depends on the implementation though. Having a long-lived refresh token may seem to be a good idea, but is not. To understand this better, let’s consider a scenario where an attacker gets hold of a refresh token. Now the attacker can keep accessing that user account till that particular refresh token is not invalidated in your database.

Going through ITEF RFC 6749 and ITEF RFC 6819, you’ll understand why refresh token should be used only once and why rotation of refresh token is required. Well, good news, you don’t really need to go through the whole doc. Here is an important quote from this documentation:

“The authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.”

We at SuperTokens are working on a product for session management right now which can easily solve the above problem!

Well, it’s tricky as well as complex to have a correct working solution where we can assure that refresh tokens are used at most once and are rotated correctly. The scenario where refresh token might get lost during the transit is not easy to handle either. We at SuperTokens have found a perfect solution that doesn't only do the rotate the refresh token on each use but also helps to identify the token theft scenario, i.e. if someone has stolen your refresh token.

Well, of course, the solution also takes care of preventing various session related attacks such as XSS, CSRF. If you want to read more about this solution, you can head over to Supertokens.

A general rule of thumb is "don't roll your own security".

Firstly answering the main question, whether the security scheme using passwords, short-lived access JWTs, and long-lived refresh tokens a good way or not, it is. Well, it depends on the implementation though. Having a long-lived refresh token may seem to be a good idea, but is not. To understand this better, let’s consider a scenario where an attacker gets hold of a refresh token. Now the attacker can keep accessing that user account till that particular refresh token is not invalidated in your database.

Going through ITEF RFC 6749 and ITEF RFC 6819, you’ll understand why refresh token should be used only once and why rotation of refresh token is required. Well, good news, you don’t really need to go through the whole doc. Here is an important quote from this documentation:

“The authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.”

We at SuperTokens are working on a product for session management right now which can easily solve the above problem!

Well, it’s tricky as well as complex to have a correct working solution where we can assure that refresh tokens are used at most once and are rotated correctly. The scenario where refresh token might get lost during the transit is not easy to handle either. We at SuperTokens have found a perfect solution that doesn't only do the rotate the refresh token on each use but also helps to identify the token theft scenario, i.e. if someone has stolen your refresh token.

Well, of course, the solution also takes care of preventing various session related attacks such as XSS, CSRF. If you want to read more about this solution, you can head over to Supertokens.