Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should Refresh Tokens in JWT Authentication Schemes be Signed with a Different Secret than the Access Token?

I have a very simple question that is essentially as stated in the title.

When implementing a JWT authentication scheme that incorporates short-lived access tokens and longer term refresh tokens, should these two token types be signed with different secrets?

I have been learning more about this authentication scheme recently and in my reading I didn't come across a strong opinion or conclusive answer to this question. Some brief Googling and searching Stack Overflow didn't produce any meaningful answers either.

Thank you for your time!

like image 529
tomking Avatar asked Jul 25 '20 18:07

tomking


People also ask

Do you need client secret to refresh token?

Typically, refresh tokens are only used with confidential clients. However, since it is possible to use the authorization code flow without a client secret, the refresh grant may also be used by clients that don't have a secret. If the client was issued a secret, then the client must authenticate this request.

Is refresh token more secure than access token?

By using refresh tokens, the access token can remain short-lived (which is desirable in case the access token is leaked or stolen somehow), and the refresh token can remain long(er)-lived, allowing the Client to get a new access token when one expires without requiring the user's permission (again).

How do I refresh JWT tokens?

In the URL field enter the address to the refresh token route of your local API - http://localhost:4000/users/refresh-token . Click the Send button, you should receive a "200 OK" response containing the user details and a JWT token, and a cookie containing a new refresh token.

Do refresh tokens need to be encrypted?

You may want to use encryption for the refresh token, too, but the key would need to be bound to a user's session at your local machine (otherwise, the user would need to provide it during "sign in" process in order for the application to decrypt the refresh token).

What is authentication using JWT?

Authentication Using JWT and Refresh Token — Part 1. Authentication using JWT (JSON Web Token) is very useful for developing cross-platform applications. The flow of the authentication process is : User logs in using their credentials.

How long do JWT access tokens last?

Authentication is implemented through JWT access tokens along with refresh tokens. The API returns a short-lived token (JWT), which expires in 15 minutes, and in HTTP cookies, the refresh token expires in 7 days.

What is the difference between JWT and refresh token?

The API returns a short-lived token (JWT), which expires in 15 minutes, and in HTTP cookies, the refresh token expires in 7 days. JWT is currently used for accessing secure ways on API, whereas a refresh token generates another new JWT access token when it expires or even before.

What is a refresh token and how to get it?

The primary purpose of a refresh token is to get long-term access to an application on behalf of a particular user. In a nutshell, a refresh token allows any website or application to regrant the access token without bothering the user. Here are its benefits: What is a JWT (JSON Web Token)?


Video Answer


2 Answers

Answer: No

Why?

2 tokens we're speaking of are

  1. access token
  2. refresh token

Cryptographically there is no upper-bound on key-usage that I'm aware of for either HMAC, RSA or ECDSA. So signing with the same key is totally reasonable to protect from existential forgery.

However, if your access-token and refresh-token issuing endpoints are on separate servers, from a key-management security perspective you may wish to sign with different secrets to contain a compromise of one of the two secrets.

like image 64
JoeKir Avatar answered Oct 07 '22 00:10

JoeKir


My intuition tells me to separate the secrets for the two tokens. But not because of security reasons. I mean, if on of the secrets leaks then you are done. And the attack surface is IMHO the same if there is one secret or two.

The reason for me to keep the secrets apart would be usability and error prevention. Developers sometimes tend to do stupid things, like mixing stuff. One day the developer will try to send a refresh token in place of an access token. If the secrets are different - the token will be simply rejected. If the secrets are the same - what happens next is beyond my imagination (so I would like to prevent this).

like image 21
Marek Puchalski Avatar answered Oct 07 '22 01:10

Marek Puchalski