How to additionally secure a REST service that is already using an OAuth 2.0 access token?

I've got the following REST services:

• An Aggregator service that is exposed to the outside world. It is secured by a user OAuth 2.0 access token. This Aggregator calls the Internal service.
• The Internal service is on a network-level not exposed to the outside world. It is also secured by the same user OAuth 2.0 access token. The access token is passed from the Aggregator to the Internal service.

Now let's say the Internal service is by accident exposed to the outside world. In theory, users could then make changes to the Internal service that should not be allowed.

Is there a way to additionally secure the Internal service, so that users can't access it even though it would be exposed to them by accident?

Would it be possible or wise to use both a Machine to Machine (M2M) token and a user token to secure the Internal service?

The most correct OAuth way to design this is to use scopes and claims. Doing this effectively allows access tokens and the user identity to flow between microservices, with the right protections and without security concerns. It is best explained by an example.

SCENARIO

Consider an online sales business scenario. A client interacts with an orders service, which calls a billing service. The client does not call the billing service, yet user initiated operations are performed there.

ACCESS TOKEN FLOWS

How scopes are designed is not defined by the OAuth standard. Usually they are designed by architects, for end-to-end business flows. An example is shown here, where each API receives and verifies a JWT access token on every request. Note that sometimes the client sends a different credential, eg a cookie or reference token, but these get translated to JWT access tokens, which are delivered to APIs.

The user identity flows from the Orders API to the Billing API. It remains verifiable and auditable, since it uses the JWT format. Both APIs validate the JWT on every request, in a zero trust manner.

The APIs also check for required scopes. In this example I have made the scope the same for each microservice, since they both cover the same business area. The Billing API may only allow this scope for the Create Invoice operation. If the access token is sent to any other Billing endpoints, or any other API where the scope is insufficient, it is rejected immediately with a 403 forbidden response. To create an invoice, the Billing API might add other restrictions, eg related to checks on an order ID in the payload.

After JWT verification the APIs trust the claims in the token and use them for business authorization. This would lock down what the user can do based on user identity, roles and other values. So if the user was able to use browser tools to extract their API credential and replay it using a tool such as Postman, they should get precisely the same access to APIs that they get in their UI session.

HIGHER PRIVILEGE OPERATIONS

The APIs will also be used by other users and clients, who may need to call higher privilege operations. Consider next a couple of employee apps that call the same APIs, and which might also be exposed to the internet. These might allow higher privileges and require multi-factor authentication:

Here, I am also using hierarchical scopes, such as sales:payments, which is one possible technique to design access to API endpoints. Scopes remain high level though, and only manage entry level security.

OTHER OPTIONS

There are more advanced options for flowing tokens. For example, OAuth token exchange can be used to get a different token for the same user before calling an upstream API. Most commonly this is used to get another token for the same user with a reduced scope.

It is possible to get a token with a completely different scope for an upstream API, but doing so may weaken security in some cases. Solutions that do this often use the client credentials flow, to get a token with a scope such as billing, then pass the user ID in an unverifiable header or URL path segment. Thus the token may have access to data for too many users, and a malicious party with such a token might change the user ID.

Infrastructure solutions alone, such as requiring mutual TLS for the Billing API, also have some problems. They may prevent access to that API by genuine clients. This can work against what the business owners want. In the above example, it would prevent the finance app from being able to call the Billing API.

SUMMARY

An infrastructure solution might be the best short term tactical solution, if you need one. As a future direction though, aim to use the zero-trust ingredients that OAuth provides, by using scopes and claims in the best ways.