Understanding authentication flow with refresh and access tokens on nodejs app

Question

I know there are already many posts about Oauth, Oauth2, JWT, etc.. I have read many and I more confused than ever so I am looking for some clarification. I will propose my view on the subject and I hope somebody can tell me if my implementation is secure enough or what I am doing wrong and how to improve it.

I am building an API Rest server for serving my resources to my users. Let's suppose it is a bank app where users can deposit, withdraw and transfer money.

I am using nodejs, hapijs, jsonwebtokens, and bcrypt for my server. I want to implement two token authentication flow (Oauth2).

This is the way I am doing it:

1. User logs in to the auth server by giving some credentials (username and password).

2. The server verifies the user's credentials, if they are valid, it will grant access to the user and return a refresh token and an access token.

   • These tokens are saved into the local storage of the browser or mobile device.

   • The access token:

     • is signed as a jsonwebtoken.
     • contains issued date, expiration date (5 min), user data (id, username).

   • The refresh token:

     • is signed as a jsonwebtoken and encrypted with bcrypt.
     • contains a unique identifier
     • may contain an expiration date
     • is saved in the database.

3. As long as the access token is valid, that means, it has not expired and contains valid user data, the resource server serves the user the requested resources.

4. When the access token is no longer valid, the auth server requests the client to provide a refresh token in order to issue a new access token

   • The server receives the refresh token from the user, decrypts it, compares it to the one in the database, checks if it has been revoked, and checks its unique identifier.
   • If the refresh token passes all tests, the server issues a new access token to the client.
   • If the refresh token fails one test, the server requests the user to re-authenticate.

Notes: I am trying to avoid the usage of cookies.

Questions:

• If the user is able to steal an access token, I guess it can also steal the refresh token. So, how can I make the refresh token more secure?
• Is my perspective of the Oauth2 flow correct?
• What can I improve?
• Am I missing something?

Auditory

What kind of clients will be consuming your service? – Footnote

@Footnote I would say public. – Auditory

I read a bit more about client types, and I have to say that both clients will be consuming my service, I believe. I will have a web app, and a native app made with react native; I don't know if it considered native or not though. I will be using https. – Auditory

@Auditory Why would you encrypt refresh_token? – Cantabile

I have the same problem. Another question I can add is "Does the user send both refresh/access tokens in his request?" – Renaerenaissance

Answer 1

The reason OAuth2 is so confusion to many people is because it uses different authentication flows depending on what kind of client is used.

OAuth2 distinguishes two client type, confidential or public. Next to that, there are 2 grant flows that are redirection based (auth code and implicit) which are meant to be used with a browser or browser control.

The other two flows (resource owner password and client credentials) are meant to be used from non-browser apps (CLI, background services, trusted mobile clients).

I've described the different flows and when to use them in more detail in this answer here.

Footnote