Generating refresh tokens and access tokens in node server

Question

I'm building mobile and a web app. Both apps will be talking to a node server. I am using JWT for authentications.

Currently, I have the following code to generate an access token:

const token = jwt.sign({ user: body }, "top_secret");

I'm really confused about refresh tokens and access tokens:

1. How to create a refresh token?
2. What do refresh token look like?
3. Can I create a refresh token - similar to the way I'm creating an access token?
4. Is the refresh token only used to generate a new access token?
5. Can the refresh token be used as an access token?
6. How do you invalidate an access token

7. How do you invalidate a refresh token? Examples I've seen used databases to store refresh tokens. The refresh tokens are deleted when you want to invalidate an access token. If the refresh token would be stored in the database on the user model for access, correct? It seems like it should be encrypted in this case

8. When the user logs into my application, do I send both access token and refresh token? I read somewhere (can't remember where) that it's not good practice to send an access token and refresh token.

9. If its bad practice to send both access and refresh tokens, when do you send a refresh to the client? Should there be an endpoint where the clients request an access token?
10. Whats a good expiry time for access tokens and refresh toekns

Answer 1

Please note that in typical OAuth2 scenarios, the server issuing tokens (authorization server) and the API server consuming access tokens (resource server) are not the same. See also: Oauth2 roles.

To answer your questions:

1. You generate a string of sufficient entropy on the server and use it as a primary key to a database record in the authorization server. See refresh token syntax.

2. From https://www.rfc-editor.org/rfc/rfc6749#section-1.5,

A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client.

3. You can, but refresh tokens are typically not structured tokens (like JWT) since they're consumed by the same server that issued them.

4. yes

5. no

6. Unless you're using introspection tokens, there's not a good way to invalidate them. Just keep their lifetime short.

7. Delete if from the authorization server store. If the refresh token cannot be found on the server, it cannot be used to refresh an access token. A refresh token is typically just a primary key to a database record holding data about the client, user and expiration of the refresh token. While you don't want to leak your refresh token, it typically does require the client using them to present client credentials to use it.

8. The user signs in at the authorization server. It returns an access token and refresh token (if your client is confidential) to the client. The client uses the access token alone to access your data on the resource server.

9. Your client uses the refresh token in a call to the authorization server to get a new access token. So your client sends only the access token to the resource server and only the refresh token to the authorization server.

10. That depends on your threat model. When your refresh token expires, the user is forced to authenticate again. Some products use refresh tokens that never expire, others use refresh tokens that are only valid for hours or days.