How to do an external login authentication?
I am needing to develop a system to be used by the user. The user will be registered in another system, where we will have the registration, contracted plans and financial control of the same...
The idea is that when the user tries to log in to your system, instead of authenticating the user's information within the database, it goes to the "master" system, authenticates the user and provides the information of his plan...
Then from there the user receives the authentication confirmation from the "Master" System and can use your system...
My doubt is in how do I do it safely? I don't want to expose user information and especially, I don't want to expose the "Master" System that will have very important data inside it...
4 answers
An "indirect" login is not much different from a "direct"login. The user presents his credentials to system a, system A presents these same credentials to System B, which in turn responds with an "ok" or no. The differences are as follows:
-
It is important that system a itself authenticates with System B (so that B knows that it is in fact communicating with A). How to do this will depend on your architecture, but a common medium and secure is to use SSL/TLS communication between servers, where A authenticates itself through a "client-side certificate" (client certificate ).
I have no experience with PHP, but this question in Soen suggests using
curlfor server-server communication. this post seems to me to give an overview of the process. -
Once the servers are authenticated, A can send the credentials received from the user to B normally. However, since this is only done once (at login), A session token is required to 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 too long, to expire the session after X minutes, to disconnect or not when closing the browser, etc. Server B does not care about the situation of the user, if the trusted server a asked for information from a user to B, he must simply deliver! It does not make much sense for server B (back end ) to assume for itself responsibilities that would be of server a ( front end)...
What can go wrong, however, is some vulnerability on the server causing him to make incorrect requests to server B. If Mallory stole Alice's account and introduced himself to A as Alice, A will hand back Alice's personal information, and has nothing to do with it. B can do about it. What you can do is try to avoid "catastrophic" results, like 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 if it were an ordinary customer-taking the same steps to sanitize the inputs passed by A as it would in relation to an unreliable external customer.
That is, although B at first trusts A, he does not " trust trust" - so the additional validation adds to the "in-depth defense".
If you do not require Single sign on , you can use a Web Service SOAP (whose purpose is to integrate) with WS-Security running on https.
XML and WebServices ( link for specification ) are documented standards and are supported by W3C
-
Your information is protected by https and you can set policies for who can or can't try to make a request to logon
Any other platform that supports XML can reuse its service (Android, Python, etc ...).
The implementation of " how " and "where" will be validating the login, is its implementation, can be in bank, LDAP or delegate to another service.
Complementing @Bacco's method in your question, you have a client of mine that uses the quoted model. The (extremely simple) logon system is java, however, subsystems there are in PHP, .NET, Ruby and Java. On the First Call of these subsystems, the token (?token=ABCDEFGHIJK) and through a commonly used component, this token is validated and we are able to identify the user logged in by it.
Additional
Beware of premature optimization , and don't try to reinvent the wheel to patterns that are already evident to work.
The method of sending is the normal POST as you already use it, but we have to think about security, see the following points:
- "system and" master " servers should only communicate between they. Infra staff can help you set up your firewall (or they themselves can do) so that this communication between systems do not be made from another source.
- using SSL communication in communication between servers (sending POSTs between them must be encrypted);
- anti-XSS techniques can be used in process, more information here: Cross-site scripting ;
I believe that following these 3 steps, you already leave your system safely to perform the necessary authentication.
Success!
This system that the user has to access " B "to have access" a " can be done with curl/php where you can take the values set by the user and manga for system a, such as curl.