Right splitting them up into logical Microservices would be the logical solution to reducing the API surface area into logical groupings.
If you need to make inter-service requests you can use the Service Gateway to transparently call internal and external services through the same API.
Authentication across multiple Microservices / sub domains
JWT is ideal for authentication across Microservices where only a single “Auth” Service needs to be configured to enable Authentication and be able to issue tokens, as JWT’s are stateless all other Microservices need only be configured with the Auth Key used to validate the tokens which contain the encapsulated Authenticated User Session.
Another solution is to use a Reverse Proxy so all Microservices appear that they’re from the same domain, e.g:
- api.example.com/products -> products.example.com
- api.example.com/salesorders -> salesorders.example.com
- api.example.com/customers -> customers.example.com
Where if you’re using any Session-based Auth Providers the Cookies will be sent to all Microservices when requesting it through the external API and as long as each Microservice is configured to use the same distributed caching provider, each service will still have access to the same Authenticated UserSession.
An alternative to using a reverse proxy is to configure to use domain cookies so that browsers will also send Cookies to all sub domains as well.