6

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. – Robert Harvey Feb 19 '18 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 '18 at 4:28
  • One-use tokens are ok. Problem is the long connection. – Laiv Feb 19 '18 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. – Christian Sauer Feb 19 '18 at 9:06
3

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.

0

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.