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.

Joe Kennedy
  • 69
  • 2
  • 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 03: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 04:28
  • One-use tokens are ok. Problem is the long connection. – Laiv Feb 19 '18 at 07: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 09:06

3 Answers3

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.

Lewis Pringle
  • 2,935
  • 1
  • 9
  • 15
  • 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 '21 at 18:34
  • 2
    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. – Lewis Pringle Oct 29 '21 at 20:59
2

securing our multiple micro-services. The major concern is that the JWT token provided to us will expire before the call is finished.

Consider using an API Gateway to validate the lifetime of the JWT for external requests, and internal microservices (receiving requests from API Gateway & other internal microservices, i.e. internal requests) should not perform the validation (for clarity, other forms of validation remain e.g. signature, iss, aud etc). Validating lifetime of internal requests is not required because:

  1. There's no benefit.
  2. There seems to be no guides online explaining how to rightly do so in a non-trivial manner, thus indicating that this could be a non-question.
  3. In some of the guides talking about using JWT for internal microservices, there's no mention about doing so, for example:
    1. OWASP Cheat Sheet Series on Microservices Security.
    2. Netflix has a slightly complex solution, whereby the API Gateway converts the incoming JWT to a Passport which contains user context (e.g. user ID, user roles/groups). There's no mention of Passport having an expiration time, so there's no lifetime to be validated (which isn't a security concern because Passport is only used for internal communications and never exposed to the external world. Passport is not persisted by any of the internal microservices, so it is effectively "scoped to the life of the request [chain]").

The 2nd point of your suggestions

If JWT expires, use refresh token to get new one and place on response headers via token provider.

does not work because Token Refresh also requires supplying the Client Id (and Client Secret) of the Client that obtained the JWT, which internal microservices should not have.

Zhiyuan-Amos
  • 21
  • 1
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).

RandomUs1r
  • 268
  • 3
  • 11