How SSO Works?

| | 2 min read

Today's Internet world, urges Single Sign On for multiple web applications as an inevitable requirement. It's not an easy task to implement SSO (Single Sign On), if the web applications are developed on different platforms. User authentication and maintenance of user's "logged in session" on web applications, is completely dependent on HTTP cookies. No web browsers allow to read cross domain cookies, as if it allows, it's a security issue then. I.e; Two web applications cannot share a single cookie, if they are deployed in different domains.

Then, what SSO (Single Sign On) does? The SSO implementation is established on the following high-level architecture.

For example, if we have 3 domains, that requires Single Sign On, consider it as www.example1.com, www.example2.com and www.example3.com, We need a 'Single Sign On' (SSO) server, that can be www.ssoexample.com. As we know, browser will not store an authentication cookie for each domains in the SSO network, from the SSO server. Rather, it will store the authentication cookie for the SSO server (www.ssoexample.com)

There may be unlimited number of client sites (in our example its only 3 sites) which can be under a "Single Sign On" umbrella, using a single "Single Sign On" server.

In SSO implementation, each and every request to the client websites will be redirected internally for checking the existence of the authentication cookie and setting the cookie after authorization. If the authentication cookie exists in the browser, the requested page on the client site will be served to the browser and if not exists, redirected to login page of SSO site and authorize credentials.

Initially, there will not be any authentication cookie on the SSO site. So request to any authenticated pages on the domains, www.example1.com, www.example2.com or www.example3.com redirects to the login page of SSO site via an internal redirection to check the existence of authentication cookie. When a user logged in to SSO site, the authentication cookie will be set in the browser, including the details of user as user Token.

Then, for the next authenticated page request from the browser will also internally redirects to the SSO site. SSO site will check the existence of the authentication cookie in the browser, and as it exists, it will redirect to the originally requested page with user Token. Then that client site will validate the Token and serves the page requested by user.

i.e; Once a user is logged onto any site under the defined SSO model, request to any authenticated page on any of the domains, www.example1.com, www.example2.com or www.example3.com results in an internal redirection to SSO site, www.ssoexample.com for checking the existence of authentication cookie and retrieving the user Token to serve the requested page in the browser.

Hope this brings you the confidence to play with SSO. Please feel free to get in touch with us if any doubts.