Understanding JSON Web Token (JWT) in context of web authentication

Question

Some statements regarding JWT in the context of web client-server authentication:

1. JWT are not safe against man in the middle attacks. Sending JWT from client to server security wise equals to sending a hashed password.
2. JWT can carry user details as payload. Using this data without accessing actual data in the DB is cited as one JWT feature. However this JWT data will not invalidate / update if the DB data changes.
3. Following from 2. the JWT payload in some situations should be verified against the DB and / or a timestamp should be set wisely to invalidate the JWT after some time.

A real world example where a client has to make several calls to APIs to complete just one workflow: a user wants to know the price of the shortest route from A to B. We are using two types of JWTs an "authJWT" & a "normal JWT".

• IF client has an authJWT: client requests API0 (auth API) with authJWT. API0 checks authJWT signature & user data payload against DB & timestamp < 2 days. Returns new "normal" JWT.
  ELSE: client requests API0 (auth API) with password & login for JWTs with timestamp. API0 checks password & login against DB and returns authJWT & "normal" JWT.
  In both cases: All subsequent APIs will be called with "normal" JWT and verify validity only via signature and timestamp but not against the user DB.
• Client requests API1 twice to get best match for search string for place A and place B. Server checks JWT signature & timestamp < 10s and uses JWT user data when needed.
• Client requests API2 to get shortest route from place A to place B. Server checks JWT signature & timestamp < 10s and uses JWT user data when needed.
• Client requests API3 to get price for shortes route. Server checks JWT signature & timestamp < 10s and uses JWT user data when needed.

This means that a man in the middle has to catch the call to API0 to get real access. Catching a "normal" JWT has little effect as it expires after 10s. Probably calls to APIs 1-3 could even go over plain HTTP without SSL encryption - but this of course depends on your use case. In all cases the user data in the JWT should better be encrypted separately.

What flaws does this design have? What could be improved?

Brockbrocken

Answer 1

Your post is big, so sorry if I misunderstood something

It seems you're talking about something like access token and refresh tokens. See this and this auth0 articles. Google oauth2 is using something similar:

• access token: Authorize access to a protected resource. Limited lifetime. Must be kept secret, security considerations are less strict due to their shorter life.
• refresh token: Allows your application to obtain new access tokens without needing to re-authenticate. Long lifetime. Store in secure long-term storage

In this post you can find usage recomendations:

• Web applications: refresh the token before it expires, each time user open the application and each fixed period (1 hour?)

• Mobile/Native applications: Application login once. Refresh token does not expire and can be exchanged for a valid JWT. Take in account special events like changing password

Answering your question, I think API0 acts as the refresh token server, and API1,2 and 3 needs access tokens. Avoid ManInTheMiddle with HTTPS, overall with API0

Balduin

I do not know node.js enough to recommend a library. In jwt.io you have library links for all languages. Check node.js section (only one – Balduin

I will rewrite my question to be shorter – Brockbrocken