3

I'm working on a application which is implemented using microservice architecture. There is an authentication service (A) which uses jwt standard, and there are other services in the application like S1, S2, S3 and so on. Now for example S1 receives a request, it should validate the token to see if the user is authorized or not. The validation can be achieved by:

  • Sending the token from S1 to A, then A validates the token and sends the result to S1 (which is a kind of overhead)
  • Validating the token inside S1 (which is a duplicate action inside every service, also requires secret key or public/private keys inside each service, for signing/verification)

I'm not asking about how these approaches work exactly. The questions is, which one of them is better? Or what is the best practice in this situation?

Improve this question
3
  • It depends on your needs. If you can afford one extra call to (A) for each call to (S#) then go #1. If you can't but you can afford dup code and to share secrets, then go #2. Or put an API gateway, and implement any of the two.
    – Laiv
    Commented Sep 17, 2017 at 8:22
  • @Laiv If it becomes clear that first approach is better, I would definitely make sure that my application can afford that extra call.
    – Hamid Mohayeji
    Commented Sep 17, 2017 at 18:44
  • 1
    What's better or worse is subjective rather than objective. You first determine what you can or can not to do, according the requirements and then make a choice. Not otherwise. If your auth service is a mere issuer of ID tokens, then #2 is enough. If the auth service is something more complex and really manage the authorization, then #1 is what you should go for, despite #2 being more rapid or simple. Requirements rules, not subjective opinions based on ireal premises or assumptions. The truth is that we can not answer your question because we know nothing about the needs and the requirements.
    – Laiv
    Commented Sep 17, 2017 at 20:12

2 Answers 2

Reset to default
4

Validate the token in the service by checking the signature.

The whole point of sending a jwt with claims is so you DON'T have to hit the auth service again.

Doing so introduces a bottleneck to your architecture and defeats some of the reasons for going with microservices

Improve this answer
3
  • To the OPs point, this does require each service having the public key of A (or a shared secret) and performing the verification step, but I agree it's the best way to go.
    – Paul
    Commented Sep 17, 2017 at 11:15
  • You are right. But let's assume I have tens of services. All of them should have required secrets to deal with tokens and they should all implement the same functionality for this purpose. Also, if my authentication mechanism change, every service must change either (which as you mentioned defeats some of the reasons for going with microservices).
    – Hamid Mohayeji
    Commented Sep 17, 2017 at 18:47
  • each service just needs the public key of the auth. theres no communication required. If you change the key then you only need to communicate that to the services once. So you dont have a bottleneck
    – Ewan
    Commented Sep 17, 2017 at 19:53
1

Do both. But differently. Validate the JWT in the auth service once. Asymmetric key operations are slow. Do it once. Then, in the auth service, encrypt or HMAC the token with AES, using an internal private key known only to the micro services. The micro services can use the shared AES key to quickly derive the validity of the token as authentic from the auth service gateway.

You get the performance you want and the security you need without a lot of excess stuff.

If you want a similar end result with a much fancier implementation, feel free to use TLS client certs internally between the auth service and the micro services.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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