Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.
True single sign-on allows the user to log in once and access services without re-entering authentication factors.
It should not be confused with same-sign on (Directory Server Authentication), often accomplished by using theLightweight Directory Access Protocol (LDAP) and stored LDAP databases on (directory) servers.[1][2]
A simple version of single sign-on can be achieved overIP networks usingcookies but only if the sites share a common DNS parent domain.[3]
For clarity, a distinction is made between Directory Server Authentication (same-sign on) and single sign-on: Directory Server Authentication refers to systems requiring authentication for each application but using the same credentials from a directory server, whereas single sign-on refers to systems where a single authentication provides access to multiple applications by passing the authentication token seamlessly to configured applications.
Conversely,single sign-off orsingle log-out (SLO) is the property whereby a single action of signing out terminates access to multiple software systems.
As different applications and resources support differentauthentication mechanisms, single sign-on must internally store the credentials used for initial authentication and translate them to the credentials required for the different mechanisms.
Other shared authentication schemes, such asOpenID and OpenID Connect, offer other services that may require users to make choices during a sign-on to a resource, but can be configured for single sign-on if those other services (such as user consent) are disabled. An increasing number of federated social logons, like Facebook Connect, do require the user to enter consent choices upon first registration with a new resource, and so are not always single sign-on in the strictest sense.
Benefits of using single sign-on include:
SSO shares centralizedauthentication servers that all other applications and systems use for authentication purposes and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.
The termreduced sign-on (RSO) has been used by some to reflect the fact thatsingle sign-on is impractical in addressing the need for different levels of secure access in the enterprise, and as such more than one authentication server may be necessary.[6]
As single sign-on provides access to many resources once the user is initially authenticated ("keys to the castle"), it increases the negative impact in case the credentials are available to other people and misused. Therefore, single sign-on requires an increased focus on the protection of the user credentials, and should ideally be combined with strong authentication methods likesmart cards andone-time password tokens.[6]
Single sign-on also increases dependence on highly-available authentication systems; a loss of their availability can result in denial of access to all systems unified under the SSO. SSO can be configured with session failover capabilities in order to maintain the system operation.[7] Nonetheless, the risk of system failure may make single sign-on undesirable for systems to which access must be guaranteed at all times, such as security or plant-floor systems.
Furthermore, the use of single-sign-on techniques utilizingsocial networking services such asFacebook may render third party websites unusable within libraries, schools, or workplaces that block social media sites for productivity reasons. It can also cause difficulties in countries with activecensorship regimes, such asChina and its "Golden Shield Project", where the third party website may not be actively censored, but is effectively blocked if a user's social login is blocked.[8][9]
In March 2012,[10] a research paper reported an extensive study on the security ofsocial login mechanisms. The authors found 8 serious logic flaws in high-profile ID providers and relying party websites, such asOpenID (includingGoogle ID and PayPal Access),Facebook,Janrain,Freelancer,FarmVille, andSears.com. Because the researchers informed ID providers and relying party websites prior to public announcement of the discovery of the flaws, the vulnerabilities were corrected, and no security breaches have been reported.[11]
In May 2014, a vulnerability namedCovert Redirect was disclosed.[12] It was first reported "Covert Redirect Vulnerability Related toOAuth 2.0 and OpenID" by its discoverer Wang Jing, a Mathematical PhD student fromNanyang Technological University, Singapore.[13][14][15] In fact, almost all[weasel words] Single sign-on protocols are affected. Covert Redirect takes advantage of third-party clients susceptible tocross-site scripting (XSS) oropen redirect.[16]
In December 2020, flaws in federated authentication systems were discovered to have been utilized by attackers during the2020 United States federal government data breach.[17][18]
Due to how single sign-on works, by sending a request to the logged-in website to get a SSO token and sending a request with the token to the logged-out website, the token cannot be protected with theHttpOnly cookie flag and thus can be stolen by an attacker if there is an XSS vulnerability on the logged-out website, in order to dosession hijacking. Another security issue is that if the session used for SSO is stolen (which can be protected with the HttpOnly cookie flag unlike the SSO token), the attacker can access all the websites that are using the SSO system.
As originally implemented in Kerberos andSAML, single sign-on did not give users any choices about releasing their personal information to each new resource that the user visited. This worked well enough within a single enterprise, like MIT where Kerberos was invented, or major corporations where all of the resources were internal sites. However, as federated services likeActive Directory Federation Services proliferated, the user'sprivate information was sent out to affiliated sites not under control of the enterprise that collected the data from the user. Sinceprivacy regulations are now tightening with legislation like theGDPR, the newer methods likeOpenID Connect have started to become more attractive; for example MIT, the originator of Kerberos, now supportsOpenID Connect.[19]
Single sign-on in theory can work without revealing identifying information such as email addresses to the relying party (credential consumer), but many credential providers do not allow users to configure what information is passed on to the credential consumer. As of 2019, Google and Facebook sign-in do not require users to share email addresses with the credential consumer. "Sign in with Apple" introduced iniOS 13 allows a user to request a unique relay email address each time the user signs up for a new service, thus reducing the likelihood of account linking by the credential consumer.[20]
Windows environment - Windows login fetches TGT.Active Directory-aware applications fetch service tickets, so the user is not prompted to re-authenticate.
Unix/Linux environment - Login via KerberosPAM modules fetches TGT. Kerberized client applications such asEvolution,Firefox, andSVN use service tickets, so the user is not prompted to re-authenticate.
Mobile environment - Apple added native Kerberos support inIOS 13.[21] OnAndroid aMobile Device Management service can add support for Kerberos.[22]
Initial sign-on prompts the user for thesmart card. Additionalsoftware applications also use the smart card, without prompting the user to re-enter credentials. Smart-card-based single sign-on can either use certificates or passwords stored on the smart card.
Integrated Windows Authentication is a term associated withMicrosoft products and refers to theSPNEGO,Kerberos, andNTLMSSP authentication protocols with respect toSSPI functionality introduced with MicrosoftWindows 2000 and included with laterWindows NT-based operating systems. The term is most commonly used to refer to the automatically authenticated connections between MicrosoftInternet Information Services andInternet Explorer. Cross-platformActive Directory integration vendors have extended the Integrated Windows Authentication paradigm to Unix (including Mac) and Linux systems.
Security Assertion Markup Language (SAML) is anXML-based method for exchanging user security information between anSAML identity provider and aSAML service provider.SAML 2.0 supportsW3C XML encryption and service-provider–initiated web browser single sign-on exchanges.[23] A user wielding a user agent (usually a web browser) is called the subject in SAML-based single sign-on. The user requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the user, issues an authentication request to a SAML identity provider through the user agent. The identity provider is the one that provides the user credentials. The service provider trusts theuser information from the identity provider to provide access to its services or resources.
A newer variation of single-sign-on authentication has been developed using mobile devices as access credentials. Users' mobile devices can be used to automatically log them onto multiple systems, such as building-access-control systems and computer systems, through the use of authentication methods which includeOpenID Connect and SAML,[24] in conjunction with anX.509ITU-Tcryptography certificate used to identify the mobile device to an access server.
A mobile device is "something you have", as opposed to a password which is "something you know", or biometrics (fingerprint, retinal scan, facial recognition, etc.) which is "something you are". Security experts recommend using at least two out of these three factors (multi-factor authentication) for best protection.