You have different approaches of security depending on your desire for risk mitigation. Examples (with somewhat made-up names); 1. An ingress moat - your ingre

You have different approaches of security depending on your desire for risk mitigation. Examples (with somewhat made-up names); 1. An ingress moat - your ingress makes decisions on whether someone should be allowed in, after which internally anything goes. 2. Two-stage auth - building on top of the above, internal messages need authentication/authorization for communication channels to be established. This might be basic, x509, kerberos, or federation-based protocols. Microservices environments might use SPIFFE for this. 3. Messenger auth - in addition to the above, requests need to show evidence of direct/indirect interaction with the parties involved. For example, an access JWT may be sent around since it would provide indication of a user and tenant. 4. Intermediary-authorization - a variation of the above, evidence is required on each communication channel 'hop' that the initiator(s) are authorized to make the request against a service. This may involve more centralized services to create many opaque/integrity-protected authorization decisions from an external systems view. 5. Transactional auth - another variation of 3, evidence is required specifically that a given action is authorized, including parties and potentially parameters. This might be sent directly from the original initiating party, or may be created for internal systems close to the ingress point. Note that for a service with a public API, all of these can hypothetically look identical. However, once you get to a certain amount of internal authorization checks, you naturally start to try to represent those with integrity-protected stateless tokens to avoid needing a massive centralized system with low latency consistency and high uptime needs. OAuth access and refresh tokens were designed to help there.