Single Sign-On (SSO)
Single-sign-on (SSO) authentication at present is required more than ever. Nowadays, almost every website requires some form of authentication to access its features and content. With the number of websites and services increasing, a centralized login system has become a necessity. In this article we’ll let you know what is SSO and how SSO authentication works.
What is SSO
Single Sign On (SSO) occurs when a user logs in to one Client’s system and then signed in to other Clients system 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 much more, is one of the best examples of SSO. Any user who are logged-on to one of Google’s products are automatically logged in to their other products as well.
Single Sign On usually makes use of a Central Service which organizes the single sign on between multiple clients. In the example 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 generated cookie.
- The user navigates to another Google product.
- The user is redirected again to their accounts.
- Google Accounts sees that the user already has an authentication-related cookie, so it redirects the user to the requested product.
How it works
In a basic web SSO service, an agent module on the application server retrieves the specific authentication credentials for an individual user from a dedicated SSO policy server, while authenticating the user against a user repository such as a lightweight directory access protocol (LDAP) directory.
Some of the SSO services uses protocols such as Kerberos and the security assertion mark-up language (SAML). SAML is an XML standard that facilitates the exchange of user authentication and authorization data across secure domains. SAML-based SSO services involves the communications between the user, an identity provider that maintains a user directory, and a service provider. When a user attempts to access an application from the service provider, the service provider will send a request to the identity provider for authentication. The service provider will then verify the authentication and log the user in. The user will not have to log in again for the rest of his session. In a Kerberos-based setup, once the user credentials are provided, a ticket-granting-ticket (TGT) is issued. The TGT fetches service tickets for other applications the user wishes to access, without asking the user to re-enter the credentials.
Although single sign-on is a convenience to users, it presents risks to the enterprise security. An attacker who gains control over a user’s SSO credentials will be granted access to every application the user has rights, increasing the amount of potential damage. In order to avoid malicious access, it is essential that every aspect of SSO implementation be coupled with identity governance. Organizations can also use two factor authentication (2FA) or multifactor authentication (MFA) with SSO to improve the security.
Conclusion
SSO authentication is here, decentralized systems are becoming more and more common and authentication is an essential aspect of all of them. SSO solves a big problem such as how to manage the increasing number of users across a whole ecosystem of applications and services. If you are implementing authentication for a new application or a service, consider integrating SSO from the get-go.