Splitting an application into smaller ones is part of the concept of microservices, but that's not all. There are several definitions, but one important thing is that each microservice must reflect a relevant aspect of the system.
Communication between services is usually done using HTTP and some higher level protocol. It can be an ad hoc with REST and even JSON or something more elaborate like Google Protobuf.
When authenticating, you might want to study theAuth and look for some implementation of Single Sign-On (SSO). There are a number of ways to implement this, and there are a few ready-made frameworks (I remember Josso , but it's been a while, there must be something better today.)
The basic operation looks something like this:
- Users authenticate to the SSO server and return a token to the client / user / browser.
- With each request for another service, the client includes the token.
- The other services validate with the SSO server whether the token is actually valid.
But, remembering, all this can be abstracted. There are even some services available on the internet that you can use if you want more productivity to focus on the business and not waste time creating your own solution, such as Auth0 .
A common technique in microservices is to create a "façade" service containing the entire external API of your application. It may be responsible for authenticating and authorizing each request. So you do not have to expose each service on the internet on different ports and the implementation of the microservices is transparent to the customers.