3

We are changing our application authentification architecture to switch to Json Web Token.

Actually, incoming requests first pass through an API Gateway that dispatch requests to various micro services of our stack.

The authentification and verification of the JWT passed in each request is done in the Gateway.

After authentification what would you do with the JWT ?

  1. Pass it 'as it' to the subsequent micro services ?
  2. Decode it in the gateway and only pass the decoded payload to the services ?

I see pro and cons in both solutions:

  1. Pro: we keep a standard Authentification http header all the way. Cons: We have to decode the token in each service.

  2. Pro: Token is already decoded and directly usable in services. Cons: We must use a non standard http header to pass the decoded payload.

Is there any 'standard' way in that situation ?

What's your opinion ?

Thanks !

Clement
  • 3,860
  • 4
  • 24
  • 36
  • Keep JWT in cookie. Its passed onto server in every request as a header by default. Then you can decode it in the server request handler. – Fawaz Oct 06 '17 at 08:02
  • The token will be stored in a cookie on the client side (SPA app) and passed to the API gateway on every request. The gateway will verify it and accept/reject the request. If the request is accepted, the token will be passed down to the underlying micro services. My question is: after authentification, should i pass the JWT token directly to the services, or should i pass only the decoded JWT payload ? I know that both would work, but i wonder if there is any 'best practices'. – Clement Oct 06 '17 at 08:06

1 Answers1

2

Pass JWT as is. Overhead of decoding is negligible but you make your system a bit more secure in case your gateway is bypassed for some reason. Or maybe you decide in the future to directly communicate with your microservices.

Konstantin Gusev
  • 21
  • 5