What Is Single Sign-On (SSO)? How Does SSO Work?

Art Wittman | Content Director | October 22, 2024

We all do it, and we know we shouldn’t. There’s that file on our phone or piece of paper in our wallet—or worse, a Post-it note stuck to the back of our keyboard—that lists our usernames and passwords. Then there’s the habit of using our dog’s name along with a few numbers and some punctuation.

Fact is, modern life in the web world means we’ve got to somehow track dozens of account names and passwords. Unless you’re gifted with a remarkable memory, they aren’t all going to be different. Mostly they’re simple, they’re old, and if someone really tried, they’re guessable. It’s a gift to would-be cybercriminals, and it’s 100% avoidable.

What Is SSO (Single Sign-On)?

Single sign-on technology is a partial solution to the password problem that plagues us both at work and in our personal lives. It allows us to log in once to an authentication server, which then issues certificates on our behalf that serve as verified credentials for participating apps.

Chances are that you’ve used such a system. If you’ve chosen to “Log in with Apple,” or Google, or some other large vendor’s identity management system rather than creating a new password for a web application, you’re using SSO. Increasingly, SSO is used in the enterprise, too, often in combination with other authorization technologies to both secure enterprise systems and make password maintenance tenable across dozens to hundreds of applications and services.

Key Takeaways

  • SSO eases the burden of an individual remembering many password and username combinations.
  • SSO makes life easier for IT teams by giving them just one authentication system to manage for the entire organization.
  • SSO also lets applications authenticate users to services the application needs to operate, such as those that manage network connections or check for software updates.

SSO Explained

The concept of single sign-on is straightforward: Instead of providing a username and password or otherwise identifying yourself to each application you use, you supply that information just once to an authentication server. Once that’s done, the authentication server sends out identification certificates on your behalf when you access any application that participates in the SSO system.

SSO reduces the number of usernames and passwords you need to know. It can also greatly reduce the number of times you’re asked provide identification credentials, making it easier to use a wide range of applications and more likely you’ll create stronger passwords. From the point of view of enterprise IT planners, SSO allows them to update security procedures and deploy more advanced authentication mechanisms to be used by the authentication server, letting all participating applications enjoy more secure authentication without the need for modification.

In your personal life, using a major vendor’s authentication system instead of manually setting a up new username and password on each app comes with several benefits. One primary upside is that the large vendors that supply federated identity management services are good at protecting passwords and other personal data entrusted to them by customers. A new vendor with a new application might not protect the credentials you supply so well.

How Does SSO Work?

SSO works by asking users to authenticate themselves to an SSO server rather than to individual applications. Once that authentication process is complete, the SSO server provides certificates to the applications an authenticated individual wishes to access. Certificates serve to verify the user’s identity.

Certificates are generally valid for only a certain period of time and are usually tied to the system from which individual users authenticated themselves. To participate, applications must be written in such a way as to enable them to use the SSO service. In the enterprise, IT planners will normally choose one SSO model and then require that applications use it to verify employees’ identities. This can be a problem for older, monolithic applications that create their own user credential repositories or that may not support common SSO architectures.

How SSO works to simplify digital access diagram
Here’s how SSO works to increase security, improve the user experience, and enhance productivity.

Common SSO Configuration Types

Common SSO components and concepts share several characteristics, including centralized identity management, standardization, and robust security measures. One key is interoperability—these systems need to work together to make sure the authentication process is user-friendly and operates smoothly across multiple applications. When that’s achieved, IT teams will find they’re able to mandate more secure passwords and two-factor authentication with minimal pushback.

  • SAML. Security Assertion Markup Language is a technical specification describing the structure of a document that will serve to authenticate users to applications. SAML uses the widely accepted XML standard to specify the structure of the document that identity servers—also known as identity providers—create and send to applications. These applications are often called “service providers” in SSO parlance. Any identity provider using SAML will create authentication credentials that can be used by any application that is SAML aware, making it a good choice for internet applications.

    SAML doesn’t provide a mechanism to assure that the authentication information an application receives is unaltered. That’s handled by other technology.

  • Kerberos. Created at MIT in the late 1980s as part of Project Athena, Kerberos is a complete authentication and authorization architecture. Project Athena sought to create a network of computer resources universally accessible to MIT students across the campus. Kerberos originally used the Data Encryption Standard (DES) to encrypt messages that passed between authentication servers and applications. It used 48-bit symmetrical keys, meaning the same key is used for encrypting and decrypting messages. At the time, DES was the most secure form of encryption available as a standard kept by the National Institute of Standards and Technology (NIST).

    Currently, Kerberos uses Advanced Encryption Standard (AES), which superseded DES in NIST’s encryption standards. AES specifies longer keys—up to 256 bits in length—and allows for multiple rounds of encryption, making the system very difficult to crack.

    Because Kerberos uses symmetric key encryption, it requires a trusted third party to manage keys, making it most appropriate for enterprise applications where a use domain can be tightly established, usually limited to the enterprise’s LANs and VPNs. While Kerberos can be used across the internet where no domain will be established by using a different authentication standard—public key encryption—to start the process, it’s rarely employed in this way. Kerberos can use its own credential format or be configured to use SAML. It remains popular, including with Microsoft, which defaults to Kerberos rather than its less-secure NTLM authentication system for enterprise networks.

  • OAuth. As an open authorization framework that does not include an authentication framework, OAuth is the default system when an internet application needs to access the resources of a protected service on behalf of a user. Most cloud providers, including Oracle with its Oracle Cloud Infrastructure (OCI), use OAuth to manage access to their cloud resources. Oracle also offers libraries and services that make it easy for developers to create their own applications that use OAuth.

    The following are the core components of an OAuth system:

    • The client system, generally an end user application that may want to access the resources of various services available on the internet.
    • The authorization server, which receives requests for tokens that will allow a client to access protected services. The authorization server will receive requests for tokens along with the client’s authentication certificate. It will issue access tokens that have been authorized by the resource owner.
    • The resource server, which has the information or provides the service that the client is seeking to use. It provides data or services when it receives valid access tokens from the client.

    A variety of access grant types can be specified by the access token. The various types are issued depending on the level of trust required and the nature of the client device. For instance, a smart TV might receive a different access grant than a laptop.

  • OpenID Connect (OIDC). OpenID Connect is the identity management system built for use with OAuth. Together, OIDC and OAuth provide a full SSO environment for web-based applications and internet native systems, such as mobile applications. Rather than use SAML as the basis for returning credential information, OIDC uses a JSON document known as JSON Web Tokens, described below, and RESTful protocols; both are native to the internet and simple for developers to use.

    Rather than using symmetric key encryption like Kerberos does, OIDC uses public key encryption, which better lends itself to domainless networks like the internet.

  • Smart card authentication. Systems like OIDC use public key encryption to ensure that only intended recipients can see the data exchanged with an identity management provider during and after authentication. Public key encryption is asymmetrical and involves a public key, which can be used to encrypt messages to be sent to a client or server, and a private key that’s secret and which must be used to decrypt messages.

    Usually, private keys are stored on a user’s device. Most laptops come with a tamper-resistant chip that uses Trusted Platform Module (TPM) technology to decrypt messages intended for the system. Apple and Android phones use different, but similar, systems. Apple’s is called Secure Enclave, and Android’s is called Android Knox. These technologies let the device provide its public key to any system that properly requests it and will use its private key that is never divulged to decrypt messages it receives.

    The advantage to these systems in that the device’s user doesn’t need to know anything about how encryption is handled on their systems. The disadvantage is that each device the user owns will have a unique public/private key pair, so the devices are known individually in the encryption process. If a laptop or phone is lost or stolen, its encryption system won’t help prevent access if the thief knows the owner’s password.

    Using a smart card with a chip similar to the chips embedded in credit cards lets users be authenticated with one set of keys, regardless of the devices they’re using. The chip on the card is its own microprocessor, so it must be inserted into a card reader or activated and powered using an RFID technology, such as near-field communications. Smart card security is similar to that offered by TPM chips.

  • Enterprise SSO. Large organizations with complex application infrastructures can create an enterprise SSO, or eSSO, system that is limited to the confines of its networks. Employees will appreciate needing to know only one or two passwords and usernames to get at the apps their work requires, and the organization will benefit from better, more manageable security for systems and data. These eSSO systems may prefer symmetric key encryption based on its ability to revoke keys more easily and SAML for its well-known format, and they often employ various sorts of multifactor authentication for better endpoint security.

    As SaaS applications become more common, enterprises have the choice of moving toward a system like OAuth that’s more commonly used on the internet or requiring that SaaS applications fit into the eSSO framework the company has chosen. SAML can be used within the enterprise network and across the internet. Many SaaS applications will support both frameworks for user authentication.

  • Web SSO. Web applications are likely to work better with or be limited to using OAuth to authorize user activity and OpenID Connect to authenticate users. Because the internet is assumed to be the transport, the components of a Web SSO system are defined as an IETF standard and thus tend to work in a way that web developers will expect and appreciate. Further, authentication is tightly coupled with authorization and uses access methods like REST protocols and information standards based on JSON to create a complete, extensible system. Web SSO systems are also intended to work across domains and at scale.

  • LDAP. The Lightweight Directory Access Protocol was first introduced in the 1990s to let users find resources they might want to use on a local network, such as servers or printers. It envisions an authoritative server that will know about all resources within a domain. As such, it’s not suited for internet use.

    Because LDAP is used to grant access to network resources, it includes a user authentication system with the user’s credentials stored on the LDAP server. Its user authentication mechanisms are not strong; for example, it sends passwords across the network as clear text. Encryption may be provided by another protocol, such as SSL/TLS.

    LDAP has the advantage of being flexible and extensible, so enterprises can use it to store additional information about employees, such as organizational roles and group memberships, and attributes like office location and phone number. Still, more granular access privileges are often required in the enterprise—think information on who has access to certain data—and those access rights cannot be easily managed by LDAP.

  • JWT. JSON Web Tokens are compact documents used to securely transmit information between parties in a structured way. They fill the same need as SAML documents, but in briefer format, which makes them suitable for inclusion in URLs. JWTs are cryptographically signed using public key encryption techniques to ensure authenticity. In Open Authentication (Oath), once a user is authenticated, the identity server will return a JSON ID token.

    Authorization requests to access protected resources will subsequently return a JSON access token, which must then be included with every request to the resource server. Such transactions transfer the state of the client—in this case, authenticated and authorized—as part of each request, making them so-called RESTful exchanges. REST, which stands for “representational state transfer,” is beneficial because resource servers do not need to establish and maintain sessions with every client that wishes to use the server’s resources.

    JWTs are clear text documents, so they should be used over HTTPS-encrypted connections. Tokens are usually designed such that they don’t contain sensitive data, such as personally identifiable information. Because each token is signed in accordance with X.509, the international standard for formatting public key certificates, that signature will be validated by resource servers to ensure that the token hasn’t been tampered with. JWTs are components of an OAuth/OpenID authentication and authorization system. They are designed for use by web applications, scale well, and are intended to be used across domains.

Benefits of SSO

IT and security professionals tend to be fans of SSO; they understand that it means centralizing user authentication, protecting potentially sensitive information, and managing integration with enterprise systems and applications. They’re generally happy to tackle the needed user training and to address ongoing monitoring and maintenance. That’s a direct result of several significant benefits that come with the technology.

  • Centralized access. SSO systems simplify the burden of managing user accounts and access to the many applications most enterprises and internet cloud providers maintain. User access to all applications can be granted and revoked in one place. So if, for example, an employee leaves an organization, administrators will not need to remove the employee’s credentials for each application individually. Security pros can also make changes to authentication systems in just one place, rather than needing to make changes to each application.
  • Improved security. SSO greatly reduces the number of username and password pairs employees must commit to memory. With that burden reduced, it’s reasonable, particularly for enterprises, to improve the security of authentication exchanges with multifactor authentication and strong password policies.
  • Increased employee productivity. Employees will struggle less to remember usernames and passwords when SSO is in place. Once authenticated, people can usually access applications without reauthenticating. SSO should therefore let employees get to their intended work more quickly. Depending on implementation details, they may still be required to authenticate to applications they use, but at least they’ll only have to remember their SSO credentials.
  • Reduced password fatigue. Let’s face it, no one wants to deal with dozens of username and password pairs. The difficulty of remembering complex passwords—especially if they need to be changed frequently—can lead to frustration and result in people using easy-to-guess passwords, reusing the same password for multiple accounts, or employing the Post-it Note method of password management. SSO lightens the burden.
  • Regulatory compliance. SSO may ease regulatory compliance through the benefits of centralized access management just described. Auditing and remediation are also simplified since there is just one SSO framework to check.
  • Simplified integration. A typical enterprise manages petabytes of data stored in many database instances. It’s not hard to imagine one database for manufacturing data, another for supply chain data, and others for financial data, marketing data, sales data, and so on. It’s also easy to understand how helpful it would be for salespeople to have access to inventory data, for example. A CRM system could access that data, but each salesperson must be known to the inventory management database as well as their CRM system. SSO can provide the necessary verified identity of the requester, and access tokens can help determine what data a person in each role should be allowed to see. Without SSO, the integration between the CRM and inventory system would be much more difficult to create and manage and would involve another authentication step for users or potentially weaker security for inventory data.
  • Streamlined user experience. Reducing the need to authenticate to enterprise applications and web applications generally makes for a better user experience. And because many people are accustomed to SSO via their personal online presence, there’s often minimal training required.

SSO and Security: Is SSO Secure?

First, there’s no such thing as secure, there are only degrees of security. That said, any SSO framework commercially available will be highly secure—that’s part of the point of the technology. Generally, the SSO system by itself isn’t a total security solution. Instead, it’s an important component of a secure environment. Its role as a system for both authenticating users and supplying authentication credentials to applications and other resource-providing systems is a critical part of an overall security strategy.

SSO and Privacy

SSO lends itself to better privacy, but privacy can vary with each implementation. For instance, SAML and JWT replies will, at a minimum, contain an assertion of authentication. They may also contain information, such as groups and roles that apply for the user, as well as other data that implementers choose to provide.

In web-based retail or social media, it might be useful to the application to know a user’s age, location, and other personal information. Generally, if you’re proving such personal information to Facebook, assume Facebook will provide it to others unless the privacy policy says it won’t or the app allows you to explicitly say not to share some information.

In the enterprise, SSO systems should return assertions of authentication along with relevant roles the user has in the organization. It may also be useful to offer up the company office where the user works and business phone number. Other information should be harder to get. What’s provided by default is typically dictated by HR policies.

SSO Use Cases

SSO is designed to provide users with seamless access to multiple applications and systems with just one set of login credentials. While organizations that have strict regulatory compliance requirements may find that they need to implement additional security measures, there are plenty of use cases for SSO. They include the following:

  • Enterprise applications. An enterprise typically manages dozens to hundreds of applications, each requiring that users be authenticated. Creating and maintaining identity management systems on a per-application basis is not practical for users or IT teams. SSO offers a way to authenticate employees once and then manage their authorization to use resources based on that one-time authentication.

    Assertions of authentication are typically valid for only a certain period and on a single system. More granular details on each employee’s roles within the company can be kept by the SSO system and used by applications or authorization systems to provide limited access to applications, data, and other resources.

  • Cloud-based applications. For both business and consumer use, cloud-based systems come with different identification and authorization needs versus SSO systems intended for the enterprise. For consumers, convenience may dictate that once users are authenticated, they can use the service perpetually from that device. Once logged into Gmail, for instance, you can use it and other Google applications, such as Docs or Sheets, without reauthenticating. In business, cloud service providers that offer SaaS applications or platforms and infrastructure as a service will also allow broad access to their services once the user’s identity is confirmed. Authentication is the first step in a larger service authorization scheme that lets users log in once and use a broad range of services. Service access will depend on each user’s role for each application—perhaps they’re an administrator on one application, a developer on a second, and an end user on a third. Access will also depend on what the organization has paid for.

SSO Implementation

Don’t let a lack of in-house security expertise dissuade you from SSO adoption. Managed security service providers as well as SSO vendor implementation teams are there to help. Many businesses opt to use SSO services offered by third-party providers. The company benefits from expertise, advanced security features, and scalability, and IT teams are able to focus on helping grow the business while leaving SSO management to the experts.

At a high level, implementation requires three major elements.

  1. Choosing and distributing client authentication systems that will securely collect end user input, such as username and password. Even in the enterprise, these systems are often delivered as web pages, so it’s an easy matter to keep authentication processes uniform across devices. Generally, in the enterprise, the user must be either on the company’s network or accessing it through a VPN. This requirement allows the organization to create a single, authoritative ID management system.
  2. Setting up an ID manager that will authenticate users and issue certificates on the organization’s behalf. In most shops, the ID manager will either be part of a system that also provides user authorization tokens that let applications know what an individual is allowed to do within the app or are tightly tied to the authorization server.
  3. Configure or modify applications to use the certificates and tokens from the SSO and authorization systems rather than keeping their own user ID system.

SSO Best Practices

Whether you’re implementing in-house, with help from a third party, or going with an as-a-service model, there are keys to success. They include the following:

  1. Mandate multifactor authentication (MFA). Just as SSO lets organizations enforce password policies from a single framework, it can also let organizations implement stronger identification technology, known collectively as multifactor authentication. These factors can include smart cards, applications running on smartphones, various forms of biometric authentication, and others.
  2. Use role-based access control (RBAC). Authenticating users solves only part of the problem of managing access to enterprise resources. The other challenge is to limit users’ access to only the resources they’re allowed to use. By establishing groups—like marketing, finance, manufacturing, and sales—and by establishing roles within each group for its members, access control can be both fine-tuned and kept in a central, manageable location.
  3. Audit and update standards. Having authentication centered on a single framework of mechanisms greatly simplifies auditing and the process of making updates to meet new standards as they emerge.
  4. Implement role and permission management. SSO lends itself to a zero trust philosophy. Users can access only those resources explicitly required for their roles and see only data that they have explicit permission to see.
  5. Adhere to data privacy laws. Using an SSO framework does not ensure compliance with data privacy laws, but it can make such compliance much easier to achieve and to demonstrate.

Securely and Easily Control Access with Oracle

Need to manage user identities and access for Oracle Cloud Infrastructure (OCI) and across cloud and on-premises applications? For organizations pursuing a zero trust security strategy, Oracle Cloud Infrastructure Identity and Access Management (IAM) provides the management and integration tools you need.

Interested in deploying a universal authenticator with multifactor authentication support? Oracle Access Management delivers a flexible system that can run on-premises or in the cloud. Organizations can enable these policies follow the user, regardless of device and location, to help secure access to data anywhere, anytime, from any device. Along with MFA, Oracle’s IAM portfolio supports trusted device SSO and application SSO—all necessary to achieve zero trust architecture principles and mandates.

As businesses rely on more applications, and applications rely on more services and data sources to do their work, user authentication and authorization become more difficult to manage. SSO frameworks make life simpler for both end users and application architects by simplifying the authentication and authorization process.

AI can significantly enhance the capabilities and security of SSO systems via biometric verification, anomaly detection, provisioning, and other capabilities. Learn how to get an AI program up and running securely and cost effectively.

SSO FAQs

What does SSO stand for?

SSO stands for single sign-on.

What is my SSO account?

Your SSO account is a centralized authentication service that allows you to use one set of login credentials to access multiple applications and systems. This means you have to remember only one username and password to access all of the services and resources that your organization provides. SSO accounts streamline the login process, improve security, and make it easier for users to access the information and tools they need to do their jobs.

What is an example of an SSO?

In the consumer space, large vendors such as Amazon, Google, Meta, and Microsoft can act as a source of user credentials for other applications. If you’ve been shown a dialog box that lets you either enter your credentials or login using one of the services above, you’re using SSO.