I have created a service that takes login credentials and gives back a JWT. Now the JWT is created with a secret key from this service.

I would like to use this token to get access from other micro-services, however on the micro-services, I would need to add the secret on there too. This seems quite ok if there aren't lots of microservices but what if it grows.

I could also ensure that my micro-services re-check with the auth service but that is just overloading it if the micro-services grows too.

However, I see you can send the token to the micro-service and the micro-service can see if it's authentic without validating it on with the auth service.

This is where my understanding starts to fail. How does the micro-service know that its authentic? I could just create a new token from some other site and use that to hack the micro-service if I put the same details in? I just can't see how that can be secure.

2 Answers 2


JWT is actually part of a suite of standards allowing for combinations of signing (JWS) and encrypting (JWE) a "payload", using a variety of algorithms.

The property you want these tokens to have is that they can be authenticated as coming from a trusted source; this is provided by cryptographically signing the token. If you wanted instead (or as well) to keep the tokens confidential (e.g. because they were visible to a third party), you would instead (or as well) want to encrypt the token.

The key point is that you sign the token with an asymmetric key pair.


  1. The authentication service generates the payload (e.g. {"user_id": 42}) and signs it with a private key. Only the authentication service should ever have access to that private key, because anybody with a copy of it can pretend to be the authentication service.
  2. The token is transmitted to a microservice, which verifies that it was signed. To do this, it needs only the corresponding public key. This public key can be copied everywhere, or even stored centrally in plain sight, because the only ability it grants is telling a real token from a fake one.

It sounds like you are using JWE (encrypted JWT), and so you need the same secret to create and read the JWT. That's a perfectly good model if your JWTs are always produced and consumed by the same server, but you're discovering the broader limitations of that method.

You could look into JWS (signed JWT) where the JWT is signed by the central server's private key, and the JWT's contents can be read and cryptographically verified by anyone who has the public key.

You're kinda inventing from scratch the idea of Single Sign-On (SSO), so instead it might be less work to set up like a SAML or OpenID Connect server.

  • I think you're muddling two things here: both Encryption and Signing can and should use asymmetric (i.e. separate public and private) keys. You're right, however, that signing is the important part in this scenario, and encryption is only needed if there's a possibility of the data being intercepted.
    – IMSoP
    Commented Jan 23, 2020 at 15:44
  • @IMSoP I take objection to the should part; if the JWTs are always produced and consumed by the same server, then JWE with AES-GCM is perfectly fine. Am I missing something here? Commented Jan 23, 2020 at 17:28
  • 1
    Yes, thinking about it, symmetric encryption but asymmetric signing is probably quite a common use case. Still, I think it's better to keep the two dimensions separate: the OP needs signing because they need to verify the origin of the token, and they should use asymmetric keys to avoid the problem of key distribution. That's a common pair of requirements, so commonly implemented together, but other combinations are possible.
    – IMSoP
    Commented Jan 23, 2020 at 17:32
  • Agreed, but I'll point out that if you're encrypting for yourself with AES-GCM, then you don't need an asymmetric signature because AES-GCM is an authenticated cipher. Commented Jan 23, 2020 at 17:59
  • Thank you guys, I dont have enough points to vote you both up. You are both correct it seems but think we are going to go with JWS as we already are using tokens with the system. Less work this approach. Much appreciated for your guidance
    – SecNoob
    Commented Jan 24, 2020 at 18:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .