Restrict REST API access to only registered site

Question

I have an old question that maybe is asked here many times, but still we are in 2022 maybe there is some better approach to solve this problem.

I have an API that is used by some websites (clients) that is registered in this API, Those clients use this API to display the list of services for private and public users without any authentication.

When the client registered in the API a personal access token is given to send it for each request before using the API to limit abuse of this API.

The problem with an access token in public side, is anyone can intercept it and use it outside of the site generated for wish will cause a lot of cost. Even if I reduce the lifetime of token to 10 min I still have the risque of abusing with it.

Is there any way to better secure this API other than authenticate the client for each request to get the fresh token with a lifetime in seconds?

To better illustrate the question above this is the use case:

1. The malicious user connects to the first registered site as the site list the services to the public users, the malicious user intercept the token in the header to the API
2. The malicious user come to his unregistered site and use the token

All this step can be automatised by the malicious user.

Edit: I cannot change the client implementation or ask him for any change, I search something to reduce abuse not at 100 % but to make abuse a little complicated, like using origine domaine name, CORS, ...

Answer 1

The vast majority of access tokens used today are bearer tokens. This means that the resource server will accept the token if it is valid, and doesn't care about who has sent that token. You are right, this means that a malicious user can steal your token and use it to call your API. There are more ways for an attacker to steal access tokens, not only MITM attacks (which, as noted in the question's comments are pretty much mitigated by using TLS). You can have XSS attacks if the tokens are made available to a Javascript app, or Man-in-the-Browser attacks, where the token is stolen by a malicious code running in the browser.

These attacks are usually mitigated by using short-lived access tokens (even less than 10 min) and putting rate-limiting in place. This usually is enough to prevent abuse. You can always add additional layers of protection, e.g. drop a token if the caller's IP changes, etc.

If you need stronger protection, then you can have a look at sender-constrained access tokens. These are tokens, that can be used only by the legitimate client. Sending such a token requires the client to present additional proof of possession. This is then verified together with the token itself.

There are different possibilities for implementing sender-constrained tokens, e.g. Certificate-bound tokens or DPoP.