Single sign-on authentication or SSO allows users to log in once to access multiple applications, services and accounts, and across different domains. With SSO, a user only has to log in once with their log-in credentials (username and password etc.) to access their SaaS applications. Using SSO means that a user does not have to authenticate for every app they log into. For example, if you log into a Google service such as Gmail, then you are automatically authenticated to other Google apps such Youtube, AdSense, Google Analytics, etc.
It should be noted that there is a significant difference between single sign-on and same sign-on. Single sign-on authentication (SSO) refers to systems where a single authentication provides access to multiple applications by passing the authentication token seamlessly to configured applications. Same sign-on, also known as Directory Server Authentication, refers to systems requiring authentication for each application but using the same credentials from a directory server. Single sign-on is known to be a framework and normally referred to as a solution. Generally, when people say an SSO solution, they are also talking about a software as the words can be used interchangeably.
SSO works based upon a trusting relationship set up between an application, (service provider), and an identity provider, (such as, Active Directory Federation Services). This trust relationship is often represented by a certificate that is exchanged between the identity provider and the service provider. This certificate is used as the key to verify identity information that is being sent from the identity provider to the service provider. This tells the service provider that the identity is coming from a trusted source. With Single Sign-On (SSO), this identity data takes the form of tokens that contain identifying bits of information about the user like a user’s email address or username.
Here is how the SSO process works:
An SSO token is a collection of data or information that is passed from one system to another during the Single sign-on process. The data can be as simple as a user’s email address and information about which system is sending the token. Tokens must be digitally signed for the token receiver to verify that the SSO token is coming from a trusted source. The certificate that is used for this digital signature is exchanged during the initial configuration process.
SSO is just one aspect of managing a user’s access. SSO must be combined with access control, activity logs, permission controls, and other measures for tracking and controlling user behavior within an organization’s internal systems. If the SSO system doesn’t know who a user is, then there is no way for it to allow or restrict a user’s access.
SAML-based SSO (Security Assertion Markup Language): is an online service provider that can contact a separate online identity provider to authenticate users who are trying to access secure content. SAML allows secure web domains to exchange user authentication and authorize data.
Smart card-based SSO: will ask an end-user to use a card holding the sign-in credentials for the first login. Once used, a user will not have to re-enter usernames or passwords.
Kerberos-based setup: is a system where once the user credentials are provided, a ticket-granting ticket (TGT) is issued. The TGT that is issued, gathers service tickets for other applications that the user wants to access without asking the user to re-enter their credentials multiple times.