Is my approach correct?
Probably not .
Security is not just about comparing password in the database (authentication).
Such an important point involves the level of user access (authorization), where each system usually has its rules.
I would say that authenticating the user to a new application without taking into account the security rules and business rules of existing applications is a direct breach of security.
The traditional approach to implementing integration, whether using SOA or any other integration model, is to delegate calls to existing systems so that they execute the appropriate business rules and return the correct values.
How to do this in practice is another story.
One way is to use Web Services, where each application provides the required endpoints and the main application fires them according to the information it needs to obtain. Web Services can be implemented with SOAP protocol or Lighter with REST.
2.
Another way, if the applications are modular, is to include modules (JARs, for example) from the other applications within your integration application and then directly execute the methods of the APIs. The disadvantage is that your application needs to include all the other and update the versions as needed, as well as provide the configuration needed for other applications to run. It seems complicated, but I've seen it work in practice, though I do not consider it ideal.
As I understand your question, each application has its own authentication method, that is, each store its user information in its own way. I believe the first, most important and most painful step is to centralize this information so that all applications use a common user registration module.
Each application can still run the authorization independently, but without a unified sign-in for authentication you will have many headaches when users try to access resources from different applications. The first (and most common) problem is the synchronization of the registration information.
