We are planning to use JWT (JSON Web tokens) in an application project, which is a set of multiple distributed web services allowing SSO authentication (single sign on). So there is a single central identity server which creates JWTs. Every call to any of the actual web services must be authenticated with a JWT previously obtained by the client from that identity server.

The following idea came up on how to use public/private RSA key pairs to limit security risks in key distribution.

The server has its own private/public RSA key pair. When creating a JWT, it signs it with its own PUBLIC key. The identity server keeps this "public" key private. But it distributes its "private" key to all services. When a client uses such a JWT with one of the web services, the service uses the "private" RSA key to decrypt and verify. Services do not need to contact the identity server for verification, which is one of the purposes of using JWTs in the first place.

In other words, the usual roles of "private" and "public" keys are reversed. This would allow to generate a new private/public RSA key pair relatively frequently, such as daily, to protect even against temporary security breaches on the identity server / seizing of hardware etc. Anyone in possession of the "private" key cannot generate fake JWT tokens on his own, because he does not possess the "public" server key. It does not even matter if anyone "steals" that "private" key - they can only verify tokens with it.

This has an advantage for single-sign-on scenarios: the client needs to get a JWT only once and can make multiple calls to all services allowing such a token without having to constantly re-authenticate. The token obviously would have a short life time such as 1 hour. It helps where multiple web services are required to get a single final output result. (We don't have the scenario where only 2 parties are involved where a server could use the public key of the recipient to encrypt.)

On first glance, this appears like an ingenious method of security JWT tokens. I could not find any reference on the web so far to someone implementing it this way. But I am sure someone else must have thought of this. It appears safe, on first glance at least.

Is there any experience or data which we haven't thought of which makes this scheme insecure?

  • Have you looked into whether existing identity and authorization standards can meet your needs? Seems like a pretty good game for OpenID Connect. Commented May 8, 2016 at 18:32
  • Thanks. I'll be looking into this. So far it appears that while OpenID Connect is touted as "simple", it is still by far more overhead to implement than direct JWT implementations. But we may have to go that route.
    – nepdev
    Commented May 10, 2016 at 8:08

1 Answer 1


I just happened to find this question here in 2018, and I want to warn those of you back in 2016 that this is completely insecure. Anyone holding your private key can indeed mint all of the JWT that they like. If this is an RSA key pair, it is almost certainly trivial to compute the public key, given the private key.

Given the public key, it is very, very hard to find the private key (hence, the strength of RSA). Given the private key, it is easy to find the public key. Just guess the typical exponent of a public key, and see if that works.

You must log in to answer this question.

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