{"id":1818,"date":"2023-03-28T08:50:41","date_gmt":"2023-03-28T08:50:41","guid":{"rendered":"https:\/\/blog.amt.in\/?p=1818"},"modified":"2023-03-28T08:50:41","modified_gmt":"2023-03-28T08:50:41","slug":"insights-on-single-sign-on","status":"publish","type":"post","link":"https:\/\/blog.amt.in\/index.php\/2023\/03\/28\/insights-on-single-sign-on\/","title":{"rendered":"Insights on Single sign-on"},"content":{"rendered":"<p>Single sign-on\u00c2\u00a0(SSO) is an authentication scheme that allows a user to\u00c2\u00a0log in\u00c2\u00a0with a single ID and password to any of several related, yet independent, software systems.<\/p>\n<p>True single sign-on allows the user to log in once and access services without re-entering authentication factors.<\/p>\n<p>It should not be confused with same-sign on (Directory Server Authentication), often accomplished by using the\u00c2\u00a0Lightweight Directory Access Protocol\u00c2\u00a0(LDAP) and stored LDAP databases on (directory) servers.<\/p>\n<p>A simple version of single sign-on can be achieved over\u00c2\u00a0IP networks\u00c2\u00a0using\u00c2\u00a0cookies\u00c2\u00a0but only if the sites share a common DNS parent domain.<\/p>\n<p>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.<\/p>\n<p>Conversely,\u00c2\u00a0single sign-off\u00c2\u00a0or\u00c2\u00a0single log-out\u00c2\u00a0(SLO) is the property whereby a single action of signing out terminates access to multiple software systems.<\/p>\n<p>As different applications and resources support different\u00c2\u00a0authentication\u00c2\u00a0mechanisms, single sign-on must internally store the credentials used for initial authentication and translate them to the credentials required for the different mechanisms.<\/p>\n<p>Other shared authentication schemes, such as\u00c2\u00a0OpenID\u00c2\u00a0and\u00c2\u00a0OpenID 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.\u00c2\u00a0An increasing number of federated social logons, like\u00c2\u00a0Facebook 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.<\/p>\n<p>Benefits of using single sign-on include:<\/p>\n<ul>\n<li>Mitigate risk for access to 3rd-party sites (&#8220;federated authentication&#8221;)\u00c2\u00a0because user passwords not stored or managed externally<\/li>\n<li>Reduce\u00c2\u00a0password fatigue\u00c2\u00a0from different username and password combinations<\/li>\n<li>Reduce time spent re-entering passwords for the same identity<\/li>\n<li>Reduce IT costs due to lower number of IT\u00c2\u00a0help desk\u00c2\u00a0calls about passwords<\/li>\n<\/ul>\n<p>SSO shares centralized\u00c2\u00a0authentication servers\u00c2\u00a0that 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.<\/p>\n<p>In March, 2012, a research paper\u00c2\u00a0reported an extensive study on the security of\u00c2\u00a0social login\u00c2\u00a0mechanisms. The authors found 8 serious logic flaws in high-profile ID providers and relying party websites, such as\u00c2\u00a0OpenID\u00c2\u00a0(including Google ID and PayPal Access),\u00c2\u00a0Facebook,\u00c2\u00a0Janrain,\u00c2\u00a0Freelancer,\u00c2\u00a0FarmVille, and\u00c2\u00a0Sears.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 there have been no security breaches reported.<\/p>\n<p>In May 2014, a vulnerability named\u00c2\u00a0Covert Redirect\u00c2\u00a0was disclosed.\u00c2\u00a0It was first reported &#8220;Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID&#8221; by its discoverer Wang Jing, a Mathematical PhD student from\u00c2\u00a0Nanyang Technological University, Singapore.\u00c2\u00a0In fact, almost all\u00c2\u00a0Single sign-on protocols are affected. Covert Redirect takes advantage of third-party clients susceptible to an\u00c2\u00a0XSS\u00c2\u00a0or Open Redirect.<\/p>\n<p>In December 2020, flaws in federated authentication systems were discovered to have been utilized by attackers during the\u00c2\u00a02020 United States federal government data breach.<\/p>\n<p>As originally implemented in Kerberos and SAML, 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 like\u00c2\u00a0Active Directory Federation Services\u00c2\u00a0proliferated, the user&#8217;s private information was sent out to affiliated sites not under control of the enterprise that collected the data from the user. Since privacy regulations are now tightening with legislation like the\u00c2\u00a0GDPR, the newer methods like\u00c2\u00a0OpenID Connect\u00c2\u00a0have started to become more attractive; for example MIT, the originator of Kerberos, now supports\u00c2\u00a0OpenID Connect.<\/p>\n<p>Single sign-on in theory can work without revealing identifying information like email address 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 address with the credential consumer. &#8216;<a title=\"Sign in with Apple\" href=\"https:\/\/en.wikipedia.org\/wiki\/Sign_in_with_Apple\">S<\/a>ign in with Apple&#8217; introduced in\u00c2\u00a0iOS 13\u00c2\u00a0allows user to request a unique relay email each time the user signs up for a new service, thus reducing the likelihood of account linking by the credential consumer.<\/p>\n<h4><span id=\"Mobile_devices_as_access_credentials\" class=\"mw-headline\">Mobile devices as access credentials<\/span><\/h4>\n<p>A newer variation of single-sign-on authentication has been developed using mobile devices as access credentials. Users&#8217; 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 include\u00c2\u00a0OpenID Connect\u00c2\u00a0and SAML,\u00c2\u00a0in conjunction with an\u00c2\u00a0X.509\u00c2\u00a0ITU-T\u00c2\u00a0cryptography\u00c2\u00a0certificate used to identify the mobile device to an access server.<\/p>\n<p>A mobile device is &#8220;something you have&#8221;, as opposed to a password which is &#8220;something you know&#8221;, or biometrics (fingerprint, retinal scan, facial recognition, etc.) which is &#8220;something you are&#8221;. Security experts recommend using at least two out of these three factors (multi-factor authentication) for best protection.<\/p>\n<p>The above is a brief about\u00c2\u00a0Single sign-on. Watch this space for more updates on the latest trends in Technology.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Single sign-on\u00c2\u00a0(SSO) is an authentication<\/p>\n","protected":false},"author":1,"featured_media":1820,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[754,753,7],"tags":[756,755,18],"class_list":["post-1818","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-authentication-scheme","category-single-sign-on","category-techtrends","tag-authentication-scheme","tag-single-sign-on","tag-technology"],"_links":{"self":[{"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/posts\/1818","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/comments?post=1818"}],"version-history":[{"count":1,"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/posts\/1818\/revisions"}],"predecessor-version":[{"id":1819,"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/posts\/1818\/revisions\/1819"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/media\/1820"}],"wp:attachment":[{"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/media?parent=1818"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/categories?post=1818"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.amt.in\/index.php\/wp-json\/wp\/v2\/tags?post=1818"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}