2
votes

I have a multiple microservices architecture in which I intend to apply security.

My View of the Security Design: The authentication will happen with an LDAP and when the user is authenticated a JSON Web Token (JWT) will get generated using a "secret key" and the token will have the roles, expiration time etc. With every call to a microservice this token will be passed in Header for authorization. In my view I just have one single auth server which authenticates the user and generates the JWT.

My Doubt:
Now, when a microservice will receive a call (containing the JWT in Header) will it always hit the auth server to get the token verified?
If yes, won't it lead to multiple calls to auth server and thus a bad practice?
If no, how will the client verify the token and what is the scope of the auth server?

1

1 Answers

2
votes

JWTs are always signed, so that you can verify a given token without doing a call to some central auth instance. The auth server knows the secret to sign the token and all services that want to validate the token also need have a way to check this.

There are two different approaches to signing:

  • symmetric: A secret value is appended before hashing the payload. The consuming service also needs to know this secret and can verify by appending the secret to the payload received and checking the resulting hash with the transmitted hash.
  • asymmetric: By using some PKI signing/verification it is possible that only the auth server has the private key to sign the token. All consuming services then only need the public part to verify.

I prefer the second way, cause it reduces the chance of a key getting stolen. If one of the consuming services is hijacked, there is no secret lost such that the attacker can create valid tokens. Using such an algorithm could possibly take some more time / cpu cycles for validating than a simple hash used in the symmetric way.

Please see the official JWT page for an example of the different mechanisms: https://jwt.io/