Currently we are debating over securing our multiple micro-services. The major concern is that the JWT token provided to us will expire before the call is finished. (This is in the synchronous design) Here are three proposals:

  1. Client App has an 'ensure(int minutes)' method before lengthy calls, calling token provider if necessary. Let JWT expire if it hits security filter.
  2. Client App sends both JWT and Refresh Token. If JWT expires, use refresh token to get new one and place on response headers via token provider.
  3. Create "login" service. Login caches refresh info and returns JWT. Send old JWT to get a refreshed JWT via token provider.

Thoughts? Note: My vote is for #1. The rest seem insecure, but convenient.

  • 5
    For any long-running call, I would set it up so that you can get receipt acknowledgement of the request, and then expire the token. Subsequent requests can ask for status or get the result, using a new JWT token. Feb 19, 2018 at 3:58
  • Agreed with @RobertHarvey, seems like a bad design to couple the calls to a single token in any case.
    – Paul
    Feb 19, 2018 at 4:28
  • One-use tokens are ok. Problem is the long connection.
    – Laiv
    Feb 19, 2018 at 7:19
  • 1
    I like this question a lot. We have a similar problem, where a client can launch a chain of further actions. Unfortunately, each step in this chain can take a day or so. Feb 19, 2018 at 9:06

2 Answers 2


I don't understand why you think having the JWT token expire will be a problem. You should only be validating the expiry when the message hits your system (request submitted). If you have a Queue in front of your service, you should check / validate tokens before the message containing them get into the Queue. If you have a service operation which takes a long time, check the expiry at the start of processing, not the end.

One important ability created by microservices patterns is that you can reply a stream of events. This naturally means some of the data in the replay will be expired.

Expiry is intended as a mechanism to prevent users outside of your system from using 'replay' attacks against your system. Once the data has made it INSIDE your system, you should not be checking for expiry any longer.

  • While this makes sense when you only have one service, what when you have a service calling other services and there could be a long delay from the start of the request to the call of the last service.
    – Peter
    Oct 28, 2021 at 18:34
  • VERY good point I had not considered! I stand LARGELY corrected. I think if I faced this sort of situation, I would use the JWT Refresh token flow (which still works fine with the above - when you get the request - even if it takes time to be ready - you can start a token refresh while doing your other work. Oct 29, 2021 at 20:59

Client App sends both JWT and Refresh Token. If JWT expires, use refresh token to get new one and place on response headers via token provider.

Is mostly correct except they go on the request headers, not the response.

So, the web api receives a request with a valid JWT that expires in a minute and the request runs for 5 minutes, the server issues a response and the next request gets 401'ed because the jwt is expired and then a call to refresh token should be made (refresh token expiry should be > 5 minutes in this case).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.