C# to NodeJS APi - Correct workflow of Token and Refresh Token

Question

I have created a C# application connecting to a MYSQL DB via NodeJS API. (all written by myself).

I'm learning this and I'm trying to get the most secure way of organising the Token and Refresh Token.

Currently I just have the API token with no expiry, so I'm implementing:

• 5 min token
• 1 year ref token

My confusion lies with the workflow. Two options I can fathom:

1. Don't use Ref token in header "always":

• Send Token for a request.
• Token Expired - response to app
• App sends refresh token
• check refresh token exists (in mysql)
• check refresh is not expired
• New token created, sent back to app.
• App now sends the token for the initial request.

2. Send ref token in header always:

• Send token and refresh for a request.
• If token expired, check for refresh (error on no refresh)
• check refresh token exists (in mysql)
• check refresh is not expired
• New token created
• run the request using the newly generated token
• return original request response but with the new access token connected

Now the Option 1 seems... like every time there is a new token generation I'm looking at 3 calls to the server. The benefit is that the request doesn't always have that refresh key in it

Option 2 is all based in Node JS, but it means every request response would have something like

{ newTokenCreated: True,
newToken: 123345456567567567,
actualRequestResponse: blahblah }

I'm unsure what is the best way to do this as I have half written the Option 2, but to a degree option 1 seems more appropriate except then every time a token is expired there are then 3 calls just to get the new token from the API, instead of option 2 which is just one call and the app really doesnt have to do that much think, just check if it got given a new access token!

Thanks for any advice. I've watched about 10 youtube videos but can't seem to get this bit down.

Answer 1

In our application, we always send the authorization token in the authorization field, whenever authorization is required. Below is the sample request headers:

:authority: 24n3z33o7e.execute-api.ap-southeast-2.amazonaws.com
:method: GET
:path: /dev/user/profile
:scheme: https
accept: application/json, text/plain, */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,kn;q=0.8
authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6IjYxZjRmNGE2ODIxNWVhMDAwOTg2Y2UwZiIsImlhdCI6MTY0NTUwOTYzNSwiZXhwIjoxNjQ1NTEwNTM1fQ.5PcJPNliuYO0n3RTD0gjWwPZ3wW_MQsug0gP0Tr9B9Q
content-type: application/json
if-none-match: W/"a8a-NVC3K4F3Ht14zY2oA/6nJxM78uo"
locale: en
origin: https://spark.dynasty-dev.com
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.80 Safari/537.36

The authorization field contains the token. We also follow the work flow option 1 where we 'Don't use Ref token in header "always":'.

Our work flow followed:

1. Send token in request headers.
2. Token Expired - response from app.
3. User needs to login again.
4. Once user will successfully login, App sends new token
5. User will use this for further API calls with authorization