0

Background:

This is the architecture of the platform I'm working on: The current architecture

The API has several secured endpoints for accessing the database. Users login on the Front End with their credentials, and if they're valid the API returns a JSON Web Token (JWT). The JWT is generated using a secret symmetric key.

The API does not know the servers, but the servers know the API. Meaning, there could be one or many servers, but I would like to avoid updating the API with a list of all available servers.

The Problem:

There are several servers that run applications that need to make calls to the API. Currently, the way that this is being done is that each application on the server has the secret key, and creates its own JWT with it. Then that JWT is sent on the request to the API, granting access to proceed with the request.

This is obviously not ideal since the secret should exist only in one spot, and only be used by the API itself. Also, it significantly increases the risk of exposure, since the number of servers is going to grow.

Looking over this question, it seems like it may be the way to go (the server makes a request to the API, the API returns a JWT, the server then uses that JWT) - however, how do I know that the server is one of the ones I should allow access to?

The Question:

Is there a tried-and-true way to authenticate these servers without sharing the secret key? Could public/private keys be used for authentication?

Since the API does not keep track of the servers, could a server provide some data to the API which would identify them as a valid server to communicate with? Or is a white list unavoidable at this point?

Improve this question

1 Answer 1

Reset to default
3

The servers each need a own secret (shared secret or public/private keys where the public part is known to the API server or signed by it/a CA).

Each server then identifies itself and gets access to the data it is allowed!

If one server is compromised, you delete the shared secret/public key from the API server or revoke the certificate.

You can look at the OAuth 2.0 Client Credentials Grant for inspiration.

Improve this answer
2
  • Could you expand a little bit more on the implementation of this? I'm a little unclear how the server would get authenticated by the API - should it have a JWT that is signed by the API and does not expire (similar to just having the secret key, minus being able to change the payload)?
    – schil227
    Commented Nov 20, 2019 at 18:00
  • 2
    @schill either you give out a JWT that doesn't expire or the server has a shared secret or private key that can be used to request an JWT from the api server. Doesn't make much difference from a security perspective. In the first case you absolutely need the possibility to blacklist JWTs (when a server is compromised) and you don't want to accept JWT without expiration from the front end but only from servers. This might make the second option easier to implement, but in the end it depends on your existing software what's easier.
    – Josef
    Commented Nov 20, 2019 at 20:00

You must log in to answer this question.

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