At the time of development sometimes – There is an special requirement of single login for two different web-applications. This type of requirement can be achieved through a most popular method which is Single Sign On (SSO).
SSO occurs when a user logs in to one Client and is then signed in to other Clients automatically, regardless of the platform, technology, or domain the user is using. Google’s implementation of login for their products, such as Gmail, YouTube, Google Analytics, and so on, is an example of SSO. Any user that is logged in to one of Google’s products are automatically logged in to their other products as well.
How SSO Works
SSO works by means of a central service. In the case of Google, this central service is Google Accounts. When a user first logs in, Google Accounts creates a cookie, which persists with the user as they navigate to other Google-owned services. The process flow is as follows:
- The user accesses the first Google product.
- The user receives a Google Accounts-generated cookie.
- The user navigates to another Google product.
- The user is redirected again to Google Accounts.
- Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product.
When using SSO, when can distinguish 3 parties:
- Client – This is the browser of the visitor
- Broker – The website which is visited
- Server – The place that holds the user info and credentials
The broker has an id and a secret. These are know to both the broker and server.
When the client visits the broker, it creates a random token, which is stored in a cookie. The broker will then send the client to the server, passing along the broker’s id and token. The server creates a hash using the broker id, broker secret and the token. This hash is used to create a link to the users session. When the link is created the server redirects the client back to the broker.
The broker can create the same link hash using the token (from the cookie), the broker id and the broker secret. When doing requests, it passes that has as session id.
The server will notice that the session id is a link and use the linked session. As such, the broker and client are using the same session. When another broker joins in, it will also use the same session.
SSO – Using cUrl
Before using cUrl make sure that your server has cUrl installed or enabled then only the below script will work.
// Send Curl request for single sign in
$post = [
'login' => $username,
'password' => $password,
'rememberMe' => '0',
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, validateCredentialsAction::URL);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT ,3);
curl_setopt($ch, CURLOPT_TIMEOUT, 20);
$server_output = curl_exec ($ch);
// End Curl request and set id (Variable according to target site) in session
$_SESSION['_id'] = $server_output;
Although the SSO processes for different services vary slightly, the basic idea behind them is the same – using cUrl! I hope this post has helped you gain an insight into how applications integrate SSO and maybe this will help you implement SSO yourself.
If you have any corrections, questions, or have your own experiences to share with SSO, feel free to comment.