<p>This is just a general question about microservice architecture. Why do 2 or more internal services still need token auth like oauth2 to communicate with each other if the outside world doesn't have access to them? Couldn't their apis just filter internal IP addresses instead? What are the risks with that approach?</p>

<blockquote>
  <p>Why do 2 or more internal services still need token auth like oauth2 to communicate with each other if the outside world doesn't have access to them?</p>
</blockquote>

<p>You don't <em>need</em> OAuth2 or token authentication, but you <em>should</em> use it. It depends on how much you <em>trust</em> your traffic. Now in the "cloud age" it is common to not own your own datacenters, so there is another part that own your server and network hardware. That part may do a misconfiguration, e.g. traffic from another customer is routed to your server. Or maybe you setup your own infrastructure and do a misconfiguration so that traffic from your test environment is unintendently routed to your production service. There is new practices to handle this new landscape and it is described in <a href="https://cloud.google.com/beyondcorp" rel="noreferrer">Google BeyondCorp</a> and <a href="https://rads.stackoverflow.com/amzn/click/com/B072WD347M" rel="noreferrer" rel="nofollow noreferrer">Zero Trust Networks</a>.</p>

<p>Essentially, you should not trust the network traffic. Use <em>authentication</em> (e.g. OAuth2, OpenID Connect, JWT) on all requests, and encrypt all traffic with TLS or mTLS.</p>

<blockquote>
  <p>Couldn't their apis just filter internal IP addresses instead? What are the risks with that approach?</p>
</blockquote>

<p>See above, maybe you should not trust the internal traffic either.</p>

<p>In addition, it is now common that your end-users is authenticated using <em>OpenID Connect</em> (OAuth2 based authentication) - JWT-tokens sent in the <code>Authorization: Bearer</code> header. Most of your system will operate in a <em>user context</em> when handling the request, that is located within the JWT-token, and it is easy to pass that token in requests to all services that are involved in the operation requested by the user.</p>
