API Security w/o User Accounts

Question

Last week, someone automated our message API to send 10,000 messages to random people. We are planning to provide security with JWT, but we don't have a forced user-authentication system.

We considered using an token with a 1 Hour expiry, but this feels kinda redundant. What is the best approach towards utilising JWT under these circumstances?

A simple exposed api example would be - Send app link to a mobile no. via SMS.

Answer 1

So my day job involves working on a product dealing with this sort of thing in the mobile space. If I add a link(approov) while answering your question, it totally counts as work right?

I have a couple of suggestions/observations.

The first thing to do if possible is to avoid the situation where you have to trust the code running on the client. There is always a chance that someone will be able to compromise it and gain access to your API.

You don't have user authentication for your system, so the options for trying to secure the API using that are out.

The simplest way to get some level of protection is to add an API key which you embed in the client. The first way you might think to try to use this is to send it along with your API requests in a header. Then in your server you check that the API key is present. The problem with that is if someone gets hold of your client, they can inspect the traffic and lift the key from one of the HTTP requests.

You can protect the connection to the server using HTTPS, but it is still relatively easy for someone to MITM the connection if they have the client. Pinning the connection helps with this, but if someone is determined enough they can hack the binary or the javascript that is performing the pinning.

Ideally you want to avoid sending your authentication information directly. You can do this by having a secret embedded in your client along with your API key. You would use the secret to sign the request you send to the server. You can calculate an HMAC of the message body using your API secret as the key to the HMAC function. You use the API key to identify which secret to use when you verify the HMAC on the server. The advantage of this is that you never send the secret over HTTP. It is still possible to steal the key from the client though. Here's a relevant question on HMACs from security.stackexchange.com

You can try to hide the secret by obfuscating it inside your code, but depending on what language your client is written in this may be more or less effective.

At this point you probably have to stop and consider how important/valuable the access to your API is and how much engineering effort you want to spend in securing the API. You also have to consider how much work someone is likely to want to put in to break into your system.

If you are super keen there are also commercial solutions that cover parts of this space, but those do cost cash money. My colleague has written an api key article that also covers some of this stuff in more detail from the mobile perspective which is our little niche.