3

A partner company is creating an RESTful Endpoint which we want to consume.

Instead some proper way of authentication they want to give use the JWT signature key so that we can create a JWT clientside and send the JWT as JSON body to the API endpoint. They could then check if the signature is valid as they also own the signature key.

While this actually seems to get the job done it feels like abusing JWT's.

Is this a valid workflow for JWT's? if not what are argruments against it? I can't think of any valid argument against it (beside that it feels wrong).

CrazyTea
  • 297
  • 1
  • 3
  • 13

2 Answers2

1

The biggest problem I see with this workflow is that the server has to trust the information that the client includes in the JWT payload. Additionally, if the server sends the same signature key to all users, the server will have a lot of trouble confirming if a user is who they say they are. Now, if the server is sending a different signature key to each user, the best the server can do is to store records in a database to control the expiration of the signature keys, but this makes JWTs no longer stateless (since they depend on "states" stored in the server), and the advantages of this feature are lost.

Tedpac
  • 862
  • 6
  • 14
1

By far the best way to do this is to

  • use asymmetric encryption
  • generate a private/public key pair
  • Send the other party a public key
  • Generate JWTs using our private key.

Every time there's more than 1 party involved with JWT, and they individually generate/validate tokens and asymmetric encryption/signing is not used you should feel this is a red flag.

Evert
  • 93,428
  • 18
  • 118
  • 189