How to do external login authentication?

An "indirect" login is not much different from a "direct" login. The user submits their credentials to system A, system A displays these same credentials for system B, which in turn responds with an "okay" or not. The differences are as follows:

• It is important that system A itself authenticates with system B (so that B knows that it is actually communicating with A). The way to do this will depend on your architecture, but a common and secure means is to use SSL / TLS communication between servers where A is authenticated through a "client certificate" in>).

  I'm not experienced with PHP, but this question in SOen suggests using curl for server- server. This post seems to give an overview of the process.

• Once you have authenticated the servers, A can send the credentials received from the user to B as normal. However, since this is done only once (at login), a session token must be used to keep the user authenticated. Where to manage this token?

  At first I would say that this is a responsibility of server A - to manage all client-server communication, including the decision to keep the user logged in for a long time, to expire the session after X minutes, to move or not to close the session browser, etc. To server B does not matter to the situation of the user, if trusted server A requested information from a user to B, it should simply deliver! It does not make much sense for server B ( back end >) to assume for itself responsibilities that would be from server A ( front end

  What may be wrong, however, is some vulnerability on server A leading you to make incorrect requests to server B. If Mallory stole Alice's account and introduced herself to A as Alice, A will deliver back Alice's personal information, and there's nothing B can do about it. What you can do is try to avoid "catastrophic" results, such as a SQL Injection in A causes it to send B a request to get data from multiple users at the same time. To prevent this, B must treat A as a regular customer - taking the same steps to sanitize the inputs passed by A that it would take against an untrusted external customer.

  That is, although B at first relies on A, it does not "trust trusts" - so additional validation adds to "defense in depth".

If you do not have Single sign On , you can use a Web Service SOAP (whose goal is to integrate) with WS-Security running on link .

• XML and WebServices ( Link to Specification ) are documentary standards and supported by W3C

• Your information is protected by https, and you can set policies for who can and can not try to log on.

Any other platform that supports XML can reuse your service (Android, Python, etc ...).

• The implementation of "how" and "where" will be validating the logon, is to its implementation, being able to be in bank, LDAP or even delegate to another service.

Complementing the @Bacco method in your question, you have a client of mine who uses the template mentioned. The (extremely simple) login system is java, however, subsystems exist in PHP, .NET, Ruby and Java. In the first call of these subsystems, the token (? Token = ABCDEFGHIJK) is passed by parameter and through a commonly used component, this token is validated and we can identify the user logged in by it.

Additional

Beware of premature optimization , and do not try to reinvent the wheel to patterns that are already evident that work.

The method of sending is the normal POST as you already are, but we have to think about security, see the following points:

I believe that by following these 3 steps, you are already leaving your system securely to perform the required authentication.

Success!

This system that the user has to access "A" to access "A" can be done with curl / php where you can get the values set by the user and mango for system A, like curl.