How to generate a refresh token?

Question

I am implementing JWT in one of my node apps. I am wondering, if there is any definite format/ structure in which a refresh token should be generated?

By definite format I mean whether a refresh token contain any claims like a JWT?

UPDATE

Let's assume a refresh token to be: fdb8fdbecf1d03ce5e6125c067733c0d51de209c (taken from Auth0). Now, what am I supposed to understand from this?

• Is this a random unique string?
• Is this an encrypted string which has claims inside?

Gee

Answer 1

Short answer

• A refresh-token is just a random string.
• All the user-related information including claims go in access-tokens

Explanation

You should keep something like this:

{
  _id: [refreshTokenId],
  value: 'fdb8fdbecf1d03ce5e6125c067733c0d51de209c',
  userId: [userId],
  expires: [some date],
  createdByIp: [some ip],
  createdAt: [some date],
  replacedBy: [anotherRefreshTokenId],
  revokedByIp: [some other ip],
  revokedBy: [some other date],
}

Refresh tokens are random strings generated by the authentication server. They are generated after successful authentication (for example, if the username and password of the user are valid).

Their sole purpose is to remove the need to exchange user credentials repeatedly. They are different from access-tokens.
An access-token usually has information about the user (like name, claims). These are usually short-lived. JWT is one example.

To get a JWT the app has to verify the credentials.
To add additional security, and to stop bothering the user for username and password every 15 mins, we just create a signature on the server-side and forward it to the app.

Next time, whenever the app needs to create a JWT, it can just send the signature back to the server. This signature is your refresh token.

Refresh tokens are also supposed to be saved somewhere.
So you would probably create a table/collection in your database, linking the refresh-token values with userIds and ip_address.

This is how you could create a session management panel for the user. The user can then view all the devices (ip_addresses) for which we have registered a refreshtoken.

Integral

Answer 2

A refresh-token can also be generated in the same way as access-token. Just make sure to include an extra claim called "token_type" to both.

Example

{
    "token_type": "refresh",
    "iat": 1100313360,
    "exp": 1100814350,
    "context": {
        "user": {"name": "joe"},
        "type":["admin"]
    }
}

Advantages of this approach over a random string while renewing access-token:

• Not hitting database for context data (you hit anyway if there is a blacklist table)
• Noticing suspicious requests by validating the refresh-token

Downhearted

thank you for posting this. I have been thinking the exact same thing and wondering why this is not commonly called out. Instead of having to check a datasource I can tell who that refresh token belongs to and what its expiration is immediately. This seems like something everyone should want. – Cicada

Answer 3

Refresh tokens play a crucial role in OAuth 2.0 for maintaining long-term access. They can be generated using a secure random string generator. For example:

var refresh_token = randomstring.generate(8);

One Best Practice: When it comes to using refresh tokens, one recommended approach treats the process as a special type of authorization grant. In this case, when requesting a new access token using a refresh token, you would use refresh_token as the value for the grant_type parameter in your token request. This method aligns with the OAuth 2.0 specification and provides a standardized way to handle token refreshing within the broader OAuth framework.

Why to Follow: This approach allows for a seamless integration of refresh token usage within existing OAuth flows, maintaining consistency and security in token management.

Hope this give another way to look into!

Pharaoh