JWT with shared secret to share data between services of different vendors

Question

We offer a platform that provides certain data processing services. All our APIs are accessible via RESTful services. All services require authentication and authorization to work properly (user/client specific data are processed). All authorization works with JWT tokens sent using the Authorization http header. There is one authentication service that generates said JWT on login and signs it with a shared secret key.

This design has been working well so far for us. It was based on one assumption though: That user management would always be handled by us.

We now have a client project coming in where we don't want to maintain any user data. All user information should reside with our client. Users should be able to log in with our client, but then be able to use our services after log in.

The straight forward way for that would be to add a new shared secret key that'll be known to our client's authentication service and to all our services. Our client could then generate valid JWTs and we would, apart from our own, normal shared secret key, add a validation step to check if a JWT submitted was signed by our client.

The alternative would potentially be an oauth based authentication scheme. But we are reluctant to implement such scheme as it'd be substantially more effort.

So my question is: Do you see any problems or serious disadvantages with our preferred approach (shared secret key)? Is there any serious downsides that we don't see? And would it generally a way forward you'd recommend?

Answer 1

I would not share a secret. I would use asymmetric encryption like RSA and have each service generate a key-pair, then share their public keys with each other. That way they can both validate and sign JWTs created by the other as needed.