0

My customer is a company that has credentials for my webserver and I want him to let his end-users to call my API with JWT that I supply for him. this is the flow:

  1. The end-user asks for a web page from the customer's webserver
  2. If the end-user has no JWT for my webserver, the customer's server calls my API with his credentials and I give him a new JWT with an expiration of 1 hour
  3. The customer sends back the JWT to his end-user and stores it in localstorage / cookies
  4. The end-user can call my API with his JWT
  5. When the end-user gets status code 401 from my API since it expired, he calls the customer's webserver again to a specific endpoint to get a new JWT with an expiration of 1 hour for my API, and then he can call my API again.

I want your opinion about this flow, and to understand if it is reasonable. Is there a way to improve this flow? maybe the end-user should look for his token and if it expired, to avoid calling my API and skip on that part in order to short the round trip?

Yair Cohen
  • 417
  • 4
  • 16

1 Answers1

0

The concept to follow here is the refresh token.

In the OAuth flow, you can use a refresh token which can be used to get a new token when the existing auth token expires.

For more details on how to use it, you can refer OAuth article here.

lkamal
  • 3,788
  • 1
  • 20
  • 34
  • I know this is the concept, and the API key is used as a refresh token in this flow, but I don't want to let the end-user a refresh token since I want that only the customer will have the ability to get a new JWT. – Yair Cohen Oct 25 '20 at 13:44
  • @YairCohen sorry, I thought you were not aware about the refresh token as you had not mentioned that you wanted to avoid it. As you are trying to avoid this, yes- maybe the client can check the validity time of the token before invoking the API and get a new one before invoking the API. – lkamal Oct 25 '20 at 13:50
  • @YairCohen Is there any specific reason that you are not interested in sharing a refresh token with an expiry time say 6 hrs so that he needs to reach the web server for a new one only when refresh is expired? – lkamal Oct 25 '20 at 13:54
  • @ikamal sorry for not mentioning that. I'll update my post. I can't give the end-user a refresh token, since I can't generate a new JWT for him as Safari doesn't support third-party cookies and in the future chrome will not support that too. The other reason is that I don't want to give him a long expiration time without getting permission from my customer for security reasons. – Yair Cohen Oct 25 '20 at 14:06
  • @YairCohen yes, I understood your concern. So you will have to ask the clients to implement that mechanism on their end; if they feel that the process of getting a new token based on 401 is slowing things down, they can check JWT expiration time. However, given that client anyway needs to handle 401, I feel it is better keep the current solution as it is (just my thought :) ) – lkamal Oct 25 '20 at 14:13