7

I'm looking into setting up authentication between two application services. Service A is going to call service B, and I want service B to only accept (http) calls from service A, nowhere else.

I know how JWT authentication works and could implement that. If I understand correctly (I think I do, but correct me if I'm wrong), it works like this:

  • service A requests a JWT from service B (or an identity server, but let's assume point-to-point)
  • service B responds with the JWT, signed with service B's secret
  • service A makes the call to service B and includes the JWT
  • service B inspects the JWT and can know if it was actually service A that made the call, without tampering with the JWT

But is the first call actually necessary? Couldn't I just do this:

  • service A signs every request with service A's private key
  • service B decrypts the request with service A's public key
  • service B now knows if the request is really from service A

I will be working over https, and have no need for claims. All I need to know is if the request originated from service A. Because only service A is allowed to call service B, but when it does, it has access to all API endpoints (so no claims necessary).

It seems simpler to use asymmetric encryption instead of JWT, but I wonder if it's as secure, correct and standard to do so.

Improve this question

2 Answers 2

Reset to default
5

The JWT was created to handle a wide range of situations (differentiated claims, separate identity server, many users, etc.). Your situation is fairly straight forward - you have only one client (A) that needs to communicate with one server (B).

You could handle this case with JWT if you want to, but there is no need too. It would indeed be overkill, since the JWT requires some form of authentication in the first step. And if you have to set that up, why not use it all the way through? The private-public key setup you suggest would work equally well. So unless you expect your requirements to change, I would go with the one that is simpler to implement.

Something very similar to your suggestion is actually already implemented in TLS, namely client authentication. In that setup, the client has to provide a certificate to the server for authentication. You might want to look into that.

Improve this answer
2
  • The TLS option was mentioned here too, but just to be sure: that would mean installing a certificate on the machines, right?
    – Peter
    Commented Mar 9, 2018 at 15:22
  • @Peter Depends on what you mean by "installing a certificate". The client needs to have a certificate to provide to the server. It needs to be signed in a way that the server can trust it. But I don't know enough about this to tell you how to set it up in practice.
    – Anders
    Commented Mar 9, 2018 at 16:47
3

You sort of point to it, using JWT access tokens in an Oauth infrastructure, with a proper authorization server (AS) is the standardized way to do it. It gives you standard ways to tune access later, through a central service. And it scales well.

Your solution is probably secure on a small scale, if you don't need to give many users or other services access. You need to deal with key management, which could just as securely be a symmetric key.

That would make this something like Github's webhook protocol: https://developer.github.com/webhooks/

This uses a HMAC header on the request.

Improve this answer

You must log in to answer this question.

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