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.
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
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.
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.
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:
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.
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.
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 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 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.
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.
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:
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.
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.