How background services perform token based Api Authentication?

Question

I am implementing JWT token based authentication for our WebAPI in order to restrict data access through the API (e.g. client sends username / password and the api provides a jwt token valid for x hours). We currently have recurring background processes that need to access that data. What is the best practice related to this scenario?

I read somewhere that since the service is a confidential type of client that we can store the credential in code similar to access-key/secret. I don't like configuring or hard coding passwords but this seems like the valid approach for the use case.

NOTE: this question has been suggested as duplicate for where to store private keys but the crux of the question is more on ideas on which approach is better for authentication related to background services.

Answer 1

The best solution will depend a lot on what you store in your token.

if you store confidential information in your token, you will need to encrypt it and use a JWE token. In this case, you will have no choice but store a private key somewhere your service can access it.

But in most case, your API endpoint doesn't need an encrypted token: all you need is a signed one so you can verify that the data in the token is valid and therefore you can use a JWS token instead.

In this case, you have 2 options again: use a HMAC based token (in which case you'll need to store that HMAC key in a secure manner) or use an asymmetrical algorithm instead (RSA or EC-based). In that later case, all your API service will need need is the public key that matches the signature: you need that key to be store on your server in a way that makes it difficult for the key to be changed but you do NOT need the key to be secret.