1

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?

  • 1
    A better place to ask about security implications would be security.stackexchange.com. As for whether you should do one thing or another - we don't know your clients as well as you/r company does, so it's up to the project manager or a higher-up to weigh the cost against any potential benefits. – moonman239 May 14 '18 at 5:34
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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