0

Here's the deal. This might probably be a known best practice, but I haven't been able to find anything on the matter.

Suppose company X has a public facing web API server, and a public OAuth Identity Server. Its clients will get a token from the OAuth Identity Server with various scopes and claims, according to what they are allowed to do.

Now, in order to function properly, this public facing web API must also call other microservices inside the company X infrastructure, and those microservies are not public. The private APIs use the same OAuth server to authorize the tokens as everyone else. The way this is done right now is that the same OAuth token used to authorize with the public facing web API is also passed around for authorization in the private API calls.

Now, my concern is that somehow this OAuth token that is basically out in the wild (company X has no hold over how its clients manage those OAuth tokens) it may be intercepted/hacked/accessed by not so friendly parties, and then be used to access the internal private APIs in case of an attack.

Is my concern well founded? Should we separate the public OAuth token and get a private token to be used only by the public API to access the internal network? Are there other ways to mitigate risks? Or am I simply imagining a problem here?

Ccm
  • 23
  • 2

0 Answers0