What Is SSO (Single Sign-On)?
SSO refers to a feature that, once a user completes authentication (login), allows access to all systems and services linked to that authentication without requiring additional logins. This eliminates the need for users to repeatedly authenticate for each individual system, greatly improving convenience. In addition, since users no longer need to manage multiple IDs and passwords, password reuse is reduced, which also helps improve security.
The Emergence and Spread of SSO (Through the Early 2000s)
SSO was originally developed because repeatedly authenticating across multiple systems was cumbersome. It spread rapidly after the release of Windows 95, when general users within organizations began using PCs to access multiple systems.
The most widely used implementation leveraged the NT Domain feature of Windows Server, and later Active Directory (which evolved from NT Domain), to link local login authentication with Active Directory-integrated systems and achieve SSO (sometimes referred to as "integrated authentication"). Directory services other than Active Directory also offered SSO capabilities, as did standalone SSO products, but for companies already using Windows Server, Active Directory could be used without any additional licensing costs beyond the Windows CAL (Client Access License). As a result, Active Directory became the most widely adopted solution.
When using Active Directory, administrators create users within an organizational unit called a "domain," provided by a server function known as a "domain controller." When a user within the domain performs local authentication (login) on their device, they are simultaneously authenticated against the domain controller. This grants the user access to the domain and enables single sign-on (authorization) to the various servers that are resources within that domain.
The authentication method used for Active Directory user authentication is Kerberos authentication, developed at the Massachusetts Institute of Technology (MIT). It is characterized by authenticating client devices, such as PCs, against the domain controller and encrypting the communication between them.
It is worth noting that SSO at the time was confined entirely to internal corporate networks. Since cloud services had not yet emerged, it was common practice to configure Active Directory SSO for systems and servers operated in-house, making only internal systems more convenient to use. Examples include internal file servers, mail servers, portal servers, databases, and in-house applications developed to authenticate against Active Directory.
SSO and Federation (Late 2000s)
In the late 2000s, SSO continued to expand. A new identity federation technology called "federation" emerged, enabling SSO between directories that trusted one another, even if they were not the same directory. This meant that, for example, even if a parent company and its subsidiary used separate directory services, federating those directories allowed employees of the parent company to single sign-on to the subsidiary's systems, and vice versa. SSO could also now be extended beyond a single company, such as between Company A and its business partner, Company B.
The most well-known federation service is Active Directory Federation Services (AD FS). Because it was provided as a feature of Active Directory within Windows Server, it was valued for enabling federation and SSO at no additional cost. In addition, since Active Directory uses the industry-standard directory protocol LDAP (Lightweight Directory Access Protocol), federation and SSO are also possible with LDAP-compliant directory services other than Active Directory.
Federation technology drew significant attention in the late 2000s, and adoption typically occurred at the level of "federating a parent company's directory with a subsidiary's directory" or "federating a head office directory with an overseas subsidiary's directory." However, it is also true that adoption remained limited due to various technical and organizational factors, such as differing management structures between parent companies and subsidiaries (or head offices and overseas subsidiaries), the effort required to federate different directory systems operated by parent companies and subsidiaries, parent companies being reluctant to manage subsidiaries' directories, and subsidiaries being reluctant to entrust directory management to their parent company.
The Rise of Cloud and SaaS, and the Emergence of IDaaS (2010s)
The environment surrounding SSO changed dramatically in the 2010s. Previously, the typical approach to adopting a new system was to purchase software, procure hardware, build the environment, and run it on the internal network. With the advent of cloud computing, however, companies rarely built systems in-house anymore. Instead, it became common to pay a monthly fee to use SaaS (Software as a Service) over the internet, or, even when building systems in-house, to build the platform in the cloud rather than on physical servers.
From an SSO perspective, the biggest change was that the majority of authentication targets shifted from internal systems to third-party cloud services and cloud platforms on the internet (as a result, the relative importance of Active Directory for SSO declined). IDaaS (a cloud-based ID and password management service) emerged to efficiently deliver SSO across both on-premises systems and the cloud.
The single sign-on flow using our IDaaS, TrustLogin (formerly SKUID)
IDaaS solutions pre-cover authentication for major SaaS applications, so SSO can be achieved without having to build custom integrations with each SaaS application individually. Internal systems can also be supported through appropriate configuration. While IDaaS solutions support multiple authentication methods and standards, the most widely adopted is SAML (Security Assertion Markup Language).
As the use of cloud services, including SaaS, continues to grow rapidly, the IDaaS market is also expanding fast, and it is expected that most organizations using SSO will shift to IDaaS-based SSO going forward.
- Reference link: The IDaaS Market Is Growing at an Average Annual Rate of 36.5%
Benefits of Single Sign-On
1. Reduced Risk of Password Leakage
After creating numerous strong passwords, most people are forced into the low-security practice of "recording" passwords on paper or in an Excel file rather than memorizing them. With paper, there is naturally a risk of theft or loss, and even if the paper itself is not lost, there is a risk that someone could see the passwords. With Excel, risks include accidentally sending the file to the wrong recipient, a password file being recovered because the hard drive was not wiped when a PC was disposed of, or a file containing passwords being stolen after a network attack compromises a device.
In other words, an ironic situation arises: creating strong passwords forces people into managing them in insecure ways.
Single sign-on can prevent these risks with a high degree of reliability. For example, consider a case where a user manages 5 passwords for internal systems and 10 for external cloud services, for a total of 15 passwords. Memorizing 15 complex passwords is nearly impossible, but if only one password is needed, it can be memorized without being written down on paper or in Excel. This eliminates the need for insecure practices such as recording passwords on paper or in spreadsheets.
2. Reduced IT Help Desk Workload and Costs
3. Improved User Convenience and Operational Efficiency
In reality, users don't want to write down their passwords — they do so out of necessity because they cannot memorize passwords that properly comply with password policies. Once the number of passwords is reduced to a memorizable level, users no longer need to check a written record each time, saving time and effort.
In addition, since users only need to manage one password or a small number of passwords, password resets due to lost or forgotten passwords become far less common. When a password reset is required, users must stop working and contact the IT help desk, which places a real burden on them. By reducing this risk, single sign-on also reduces the need for users to contact the IT help desk, allowing them to focus on their work without being troubled by passwords.
The Cost of Single Sign-On
In both cases, pricing is typically based on the number of users. When there is no limit on the number of systems or cloud services (apps) that can be used with single sign-on, monthly fees generally range from the mid to upper hundreds of yen per user, although some products charge more than 1,000 yen per user per month. Since most single sign-on products offer a free trial period, it is important to evaluate them comprehensively based on functionality, ease of use for end users and administrators, and pricing.
TrustLogin (formerly SKUID), provided by GMO GlobalSign, is offered with no limit on the number of apps for single sign-on, no user limit, and no charge for the basic plan. With the exception of a few optional features, it is provided at no cost, offering an overwhelming cost advantage compared to other paid products. We would be delighted if you would consider including it among the products you trial.