?){kind=link}
Single sign-on (SSO) is a great way to solve the problem of having to log in again and again every time you access a new service. It’s easiest to explain it with an example:
Let’s say that you, like many people, rely on a range of Google’s services. You look up things in Google’s search engine, use Gmail to check your messages, write in Google Docs, turn to Maps when you need to find your way around, and click on YouTube when you feel like passing the time.
When you go from one of these Google services to the next, do you log in each and every time you switch?
Nope. Most people will have their Google accounts set up so that they only have to log in occasionally, like when they try to access their account from a new device, or when Google senses suspicious activity. With this rare login to just the one account, you can switch between YouTube, Gmail and all of the other services you rely on, without having to keep logging in every single time you change services.
How does it all happen? Through single sign-on.
Most of us really appreciate the convenience that single sign-on gives us, because we tend to use a large number of different services, and frequently switch between them. Having to log in each and every time would be a hindrance, and it would really slow us down in both our work and personal lives.
Single sign-on can be accomplished through a range of different techniques, but at its core, it enables us to access multiple different services, all with the one log in. It reduces friction for the user, which enhances the user experience. Single sign-on can even have some security benefits and be helpful in other areas. However, there are also a few downsides of single sign-on, which need to be considered before you implement it.
Note that single sign-on is often used to refer to accessing services within the same company. If we are talking about using one set of login credentials to access services from multiple different organizations, this is known as federated identity management (FIM). However, sometimes the term single sign-on is also used for federated identity management. We will cover federated identity management in more depth later on in the Federated identity management section.
What does signing on really do?
Before we can truly understand single sign-on, we need to take a step back and understand signing on in a more general sense, as well as the processes involved in access control.
So why do we have to log in to our accounts in the first place? Perhaps an even better question to ask is why do we even have accounts?
The simple answer is that accounts control access to sensitive and valuable information, systems and other resources. We do not want anyone to be able to access these unless they are authorized to do so.
So we need to have security controls in place that keep attackers away from this information and the systems that house it. We also need security controls that prevent anyone from accessing your account and using it to pretend that they are you.
These are the reasons why we have developed a whole host of mechanisms to restrict access to these accounts, and thus the information and systems to which these accounts have access. The systems that we have cobbled together over the years help us to prevent unauthorized access to sensitive information, systems and other resources. They also help us to keep track of any modifications, and even allow us to investigate suspicious behavior.
But how exactly do we do it?
There are five steps that need to be followed:
- Identification
- Authentication
- Authorization
- Auditing
- Accountability
Identification
In order to restrict access so that only authorized parties can enter a system, we first need to know who is attempting to gain access. This process is known as identification, and it involves a user claiming an identity.
There are a number of ways that this can be done, but one of the most common options is through a username. A user will type a username into the system, as a way of claiming, “Hey, I’m user1”.
There are a few other ways that people can identify themselves as well. Biometric identifiers like your face scan or fingerprints are becoming popular. However, it’s worth noting that these can also double as methods or authentication, which we will discuss in the next section.
Smartcards and security tokens can also act as both identifiers and methods of authentication, but these tend to be easier to steal. In many circumstances it’s probably best to use them as complimentary authentication mechanisms rather than as the sole identifier and means of authentication.
Before a user can use one of these methods to claim an identity, they must have been enrolled or registered within the system. You will have done this plenty of times when you sign up to an account. You hand over a few of your details, and give them your phone number or email address so that they can send you a message to verify that you actually have control of the number or email.
If you get a new job, the enrollment process might involve HR reviewing your identification and other documentation as part of their vetting process to find out who you really are. Then they will set up an account for you so that when you try to log in to the system for the first time, the system actually knows who you are.
Authentication
The next step is to provide authentication. However, in reality, identification and authentication often happen at the same time. If identification involves an entity claiming an identity, authentication involves the entity proving that they really are that person.
There are a few different ways that we commonly do this. The first type of authentication factor is through something that only the legitimate user should know, like a password, a key, or the answers to security questions. These are known as knowledge factors.
The second authentication factor is through something that only the legitimate user should have, such as a smart card, a security token, or a device with an authentication app on it. These are called ownership factors.
The third authentication factor is through something that only the legitimate user is or does. These include things like your face scan, fingerprint or your voice print. These are known as inherence factors.
It’s best to combine at least two of these authentication factors together. On its own, it may not be too hard for an attacker to either figure out someone’s password or steal their smartcard, but getting their hands on both is a much more difficult challenge.
So, when you go to sign on to your account, you will enter an identifier like your username, and provide one or more means of authentication, such as your password and the number in your authenticator app.
The system that you are trying to log in to will search its database for the username, and if it finds one, it will verify whether the authentication you provided matches its records. If they match, the system will authenticate you, which basically means that the system acknowledges that yes, you are “user1”.
Authorization
Once you’ve been authenticated, are you free to do what you want? Not quite. There’s still a little thing called authorization to contend with.
In most cases, we don’t want to have a security system where once someone has authenticated themselves, they then get free access to all of the systems and resources. This would introduce huge security risks, because all it would take to cause immense damage to the business is for an employee to go rogue, or for an attacker to compromise a single account.
Instead, you want to follow the principle of least privilege, and only give users access to the things that they really need. To handle this, we need authorization. Essentially, the system just keeps a record of what each user is allowed to access. When an authenticated user requests access to a resource, the system just checks the records. If the user is authorized, the system will grant them access. If not, it will deny them.
Auditing
While identification, authentication and authorization are probably the most important aspects from the user’s perspective, there are a couple of additional aspects of access control that are important for maintaining the integrity of the system.
Auditing involves keeping records of user activities, such as when they logged in, and what they accessed. These logs are critical for the final step of access control.
Accounting
One aspect of maintaining a secure system is through deterrence. If people are worried about getting caught and the possible repercussions from getting caught, then they are less likely to try and abuse the system.
This is one reason why accounting is so important, because in this step we review the records from the auditing phase, and investigate whether there have been any violations. If there have been, we can hold the perpetrator accountable for their actions, either internally within the company, or by going to the authorities.
In addition to providing a deterrent, the accounting phase also allows us to look back on logs from the past and use them to help us understand and recover from any issues that we come across, as well as to put new prevention measures in place to stop these issues from recurring in the future.
What does single sign-on really do?
Now we have a solid grounding in the fundamentals. We understand that signing on gives us a way to allow authorized entities to access a system while keeping unauthorized entities out. We also know each of the important steps involved in access control, so we’re ready to take a more advanced look at single sign-on (SSO).
If an organization only has one service for you to sign in to, single sign-on isn’t necessary. You would simply log in to your account with the username, password and any other authentication factors that may be needed. Then you could access the system and do what you needed to do. You could then log out at the end of the session, the service may automatically log you out, or you could stay logged in for future sessions, depending on both your preferences and the security options that the service allows.
If Google only offered Gmail, and none of its other services were available, single sign-on wouldn’t provide any benefits to the way that you access Gmail. But as we all know, Google offers a host of different services, which many of us rely on heavily.
It’s not hard to imagine a situation where Google didn’t offer single sign-on, and you had to have separate accounts for each of the company’s services. You would have your Gmail account, a separate one for Google Docs, another one for YouTube, etc. But this kind of setup would make your day much more tedious.
You would have to log in and out many more times as you switch between in each service, adding extra friction to each of your online tasks. Most of us are probably glad that Google offers single sign-on, because it just makes things easier.
Of course, single sign-on doesn’t just apply to Google’s services. We come across it frequently when there are multiple services to access within the one company.
We see it in Microsoft with the company’s many different tools and platforms that you can reach with the same account. The same goes for Apple and the countless different services it offers to its users. A large number of companies and governments allow you to access a variety of their different offerings, all with the same account, via single sign-on. The company you work for might have single sign-on too.
At the end of the day, single sign-on is quite simple. It allows users to authenticate themselves once and then access multiple services within one organization, as opposed to having to re-authenticate themselves every single time they switch services. Ultimately, this serves to simplify things, reduce complexity and enhance the user experience.
Single sign-on can be accomplished with a range of different techniques, some of which we will discuss in the Mechanisms for single sign-on section.
The benefits of single sign-on (SSO)
So far, we’ve mainly discussed the most obvious benefits of single sign-on (SSO); that it reduces friction, makes things easier for the user and enhances the user experience. But there are actually some other benefits as well:
Single sign-on can save employee time
By reducing the number of logins a user makes per day, single sign-on can actually help to save time and boost productivity. While it’s true that logging in may only take 30 seconds or so, when we add this up over the course of a day for each employee, and then total it across an organization, single-sign on can actually save a company a significant amount of time.
Signing on can also break workers out of their flow, so it’s possible that these 30 second breaks may result in more than that amount of lost productivity.
Single sign-on can reduce password fatigue and improve security
Another potential benefit is that single sign-on can reduce password fatigue. Each of us have dozens or perhaps even hundreds of online accounts. If you are following best password practices, this means that you should also have dozens or hundreds of unique passwords as well.
Realistically, one of the only valid strategies for keeping this many unique and strong passwords is to store them in a password manager.
Many people still haven’t gotten the memo on password managers, which generally means that they do one of several things, each of which are awful from a security perspective. They either use the same password for everything, make slight variations of the password for each account, or they simply write down each of their passwords and keep them conveniently located. Each of these choices are terrible for security, because they leave people open to credential stuffing and other attacks.
So how does single sign-on play into this? Single sign-on can help to reduce the number of accounts that each person manages. The theory is that if a person has fewer accounts, they will be more likely to use strong and unique passwords.
Let’s say we have two organizations, Organization A and Organization B, each of which have five different services that their employees need to use. Organization A offers single sign-on, so employees can log in to all of these services with one account and a single password. Organization B doesn’t have single sign-on, and each employee has five separate accounts that they have to try and remember the passwords for.
Which organization do you think will end up with more employees following good password practices?
In the case of organization A, employees only have to remember a single extra password, so it’s a much lower cognitive burden. Realistically, it’s probably not too hard for someone to remember a strong and unique password that they use for work every day, even if they don’t have a password manager.
At organization B, each employee has to remember five passwords. Some of these accounts may not get used too frequently, which would make them even harder to remember. What do you think would happen in this scenario?
A lot of employees would probably resort to reusing passwords or writing them down and leaving them at their desks. Doing either of these things would significantly increase risk, but it’s hard to blame the employees when it’s simply too hard for them to do the right thing. Ultimately, having five separate accounts for each employee may be detrimental to the overall security of organization B.
Single sign-on can lower administrative burdens
In the last section, we mentioned that if employees have to remember five passwords, they are more likely to forget some of them. What happens when employees forget their passwords all of the time? They call the help desk, and then the poor tech worker has to walk the employee through resetting their account for the thousandth time.
If an organization’s infrastructure is set up so that each employee has multiple accounts, it will result in more people forgetting their passwords, and the help desk being deluged with calls to help employees who have been locked out of their accounts.
Not only does this take up a bunch of the IT department’s time, but it also means that all of these other employees aren’t doing their jobs while they are on the phone to the help desk.
Another major administrative advantage of single sign-on is that there is just one account system to manage instead of multiple disparate systems. This can significantly reduce the overhead and make maintenance much easier. It also makes it less likely for things to accidentally be overlooked.
As an example, if an employee is fired from the company and needs to have their access removed by an administrator, it’s much easier to do if they only have to remove the privileges for a single account. If there are multiple accounts for that employee, it can increase the likelihood that one is forgotten about.
When mistakes like these are easier to make, the risks faced by the organization also become more likely to eventuate. In the example we just discussed, the terminated employee may be able to sneak back into the company and steal data or sabotage the company’s systems
The dark side of single sign-on (SSO)
So far, we’ve mainly been talking about the positive side of single sign-on (SSO). Unfortunately, there’s no free lunch, and there are downsides of it as well.
Many of the cons of single sign-on are tightly intertwined with its benefits. We’ve just talked about the advantages of users being able to access everything with a single account, and also demonstrated how centralizing access control systems can make the administration easier.
But centralizing things also tends to create single points of failure, which can increase the chances of catastrophe. If an employee uses five different accounts to do their work, and one is compromised, they will still be able to access their other four accounts. They may still be able to do a significant portion of their daily tasks.
When there’s only one account for single sign-on and things go down, it’s a whole different story. Employees may not be able to access anything, which means that the entire organization grinds to a halt until the issue can be fixed.
Single sign-on faces a similar problem when it comes to account compromises. If an employee has five different accounts and an attacker manages to figure out the credentials to one of them, this will only give the attacker access to a smaller subset of the systems and data that the employee is authorized to access.
However, when the employee has just one account for all of their services and an attacker compromises it, it means that the attacker gains access to everything that the employee can access. While any type of employee account compromise is a serious issue, the more access that this gives an attacker, the more harm they can cause to the organization.
With this increased harm in mind, organizations that adopt single sign-on also need to take steps to mitigate the dangers that can come from one of these accounts being breached. Multi-factor authentication is critical for any organization with single sign-on in place, because it makes it significantly harder for an attacker to compromise an employee account.
Federated identity management (FIM)
Now, let’s add in an additional layer of complexity, and talk about federated identity management (FIM). Instead of a situation where we have a single organization with many different services that we want to access, let’s consider accessing different services across a number of separate organizations.
How could we log in to each of these, all with the one account? Why would we even want to? What are the positives and negatives of doing so?
Federated identity management is basically the same as single sign-on, except it pushes things one step further and allows us to access services from multiple different companies, all with just the single authentication. The term single sign-on is also often used to refer to federated identity management.
In technical terms, we would consider the services of each different company to be part of separate security domains. With federated identity management, we aim to bridge these domains.
This is an incredibly appealing concept, because for most of us, our work and personal lives often involve us switching between a number of different services, each from independent companies. Wouldn’t it be much better if we had an easy way to jump between them?
What if, instead of just being able to use the one identity and a single authentication across multiple different companies, we could actually share resources between them as well?
Of course, you probably already have some of your accounts set up to do this. Federated identity management (FIM) plays a big part in this, allowing us to streamline and connect the various services that we use in our work and personal lives.
How does federated identity management (FIM) work?
In order for users to be able to use a single identity across multiple different companies or security domains, the organizations first have to come together and form a federation. Then, they have to decide on how they will all share the identities with each other. This can be challenging, because each company will have its own platform and surrounding infrastructure, which can make it hard to agree on compatible standards that they can all share.
However, there are a few common options like SAML or the combo of OpenID Connect and OAuth 2.0, which we will discuss later.
Once a group of organizations come together, form a federation, and agree on a way that they will share their identities, users can then log in to any one of the organizations and have their credentials linked up to their federated identity. This federated identity then allows them to access resources from other organizations within the federation, without having to reauthenticate themselves.
You will often notice the signs of federated identity when you go to log in to a website and you see the options to sign in with Google or Facebook, in addition to using your own account.
When you notice these options, the website that you are trying to log in to is also allowing you to use these third-party services to sign on, instead of using your own. The website is essentially trusting Google or Facebook to do the authentication so that it doesn’t have to. Ultimately, this can streamline things for users, because it means that they don’t have to set up yet another account.
However, you need to be aware that if you are using services like Google or Facebook to log in to other sites, then this generally means that at least some of your data is being shared between them and the site you are logging in to.
Federated identity management also comes with the single point of failure issue we discussed earlier. However, this time, the results can be even more disastrous, because we aren’t just talking about multiple services within the same organization. If the provider you use for authentication goes down, things could go wrong with the services that you rely on across multiple different platforms.
Security issues in federated identity management systems
Like most other security mechanisms, federated identity management systems can be abused or circumvented. Some of the most notable issues from the past include:
Russian state-actors targeting federated identity management systems
In 2020, the NSA issued a Cybersecurity Advisory warning of malicious actors targeting federated authentication environments. The agency noted two separate techniques that both began with gaining access to the target’s network.
The NSA’s documentation didn’t specify how the actors gained this initial access, but phishing to steal credentials or install malware is a likely culprit. An earlier Cybersecurity Advisory on the same exploits indicated that the actor was a Russian state-sponsored group. Such a well-resourced attacker would have a wide range of techniques to infiltrate the on-premises network of their target.
The Cybersecurity Advisory also demonstrated how the attackers exploited vulnerabilities in VMware Identity and VMware Access to compromise the federated single sign-on infrastructure.
Once the attacker was in the target’s network, one of their techniques was to compromise the federated single sign-on infrastructure. They would steal the private key or credentials that were used for signing the Security Assertion Markup Language (SAML) tokens—don’t worry, we will discuss SAML in more depth in the Mechanisms for single sign-on section. This allowed them to forge authentication tokens that could then give the attacker access to the targeted organization’s cloud resources.
If the attackers were unable to get their hands on an on-premises signing key, they would attempt a variant of this technique. It involved trying to escalate their privileges until they gained admin privileges within the cloud tenant. Once they had this level of access, they would create a “malicious certificate trust relationship” that was then used to forge SAML tokens. This compromised the security of the federated single sign-on infrastructure.
The other technique involved compromising a global administrator account and using it to assign credentials to special identities for cloud applications. These identities allowed the applications to be used to access other cloud resources. With the credentials for these identities in hand, the attackers would use the application to gain automated access to their target’s email and other cloud resources. This allowed them to access sensitive data without raising too much suspicion on the target’s network.
While Russian state actors were specifically referred to in the advisories, the NSA also noted that a range of other actors could use these same tactics. The technique used to forge the SAML tokens has been used by threat actors since at least 2017.
It’s important to be aware that these attack techniques were not made possible due to vulnerabilities in the SAML protocol, cloud identity services or federated identity management. Instead, the real issue is that the security of these mechanisms relies on trusting the on-premises systems involved in authentication, granting privileges and signing SAML tokens. Since the attacker was able to compromise these on-premises systems, it also resulted in the compromise of the federated single sign-on system.
To combat these threats, the NSA recommended hardening the on-premises systems for federation services and on-premises identity. It also advised locking down service principal usage and tenant single sign-on configurations. Ongoing monitoring of single sign-on token usage is also critical for detecting future compromises.
Covert Redirect
In 2014, a Singaporean PhD student discovered an attack that was dubbed Covert Redirect. It allowed a hacker to trick users into handing over their information through a forged authorization popup.
The attack could work against the OAuth 2.0 and OpenID protocols, which we will describe in more depth toward the end of the article. OAuth 2.0 is a protocol for delegated authorization, and alongside OpenID, it can be used for federated identity management. Among other things, these protocols allow a user to authenticate themselves on a website using a third-party provider.
The attack involved manipulating the user to think that they were authenticating themselves through a legitimate third-party window, when they were really just typing in their username and password into a fake window constructed by the attacker. Ultimately, the attack could lead to the user’s account being compromised, or them ending up with malware installed on their device.
However, the attack was only possible if both the login service and the application that a user was trying to access had poor security. It also involved a number of other critical steps in order for it to be possible, which made it quite difficult to mount Covert Redirect against victims. This meant that Covert Redirect was not as dangerous as some media outlets at the time would have had you believe, nor was it really an issue specific to the OpenID Connect and OAuth protocols.
Mechanisms for single sign-on
The following are some of the more common single sign-on solutions, either for a single organization, or for federated identity management between a group of different companies.
Lightweight directory access protocol (LDAP)
If a company wants its users to be able to use the same accounts to access multiple different services, it will need to implement some method to centralize its access control systems. One option is to adopt a directory service, which is a database that stores information about users and the resources they are allowed to access.
The lightweight directory access protocol (LDAP) forms the basis of many of these directory services, with one of the most prominent being Microsoft’s Active Directory. They are generally used as on-premise solutions for access control within a single organization. However, there can be extensions for federated identity management, such as Microsoft’s Active Directory Federation Services.
LDAP directories allow users and other parties to search for where a specific resource, service, or system is located. Users must authenticate themselves to the directory service before they can query it, and the directory service’s response will only include information that the user is authorized to access. LDAP can use a number of different mechanisms for authentication, including usernames and passwords, digital certificates and Kerberos.
A security domain is a set of users and resources that follow a single security policy. While these can operate on their own, LDAP-based directory services also make it also possible for different security domains to form trusted connections.
When these connections are formed, it allows users from one security domain to access resources on another. This helps organizations facilitate single sign-on between services that are part of different security domains.
Kerberos
As we mentioned, Kerberos can play a role in the authentication of LDAP-based single sign-on systems. However, it isn’t just limited to LDAP-related systems. The Kerberos protocol features a ticketing mechanism that allows it to play a role in other single sign-on solutions.
Kerberos was originally developed at the Massachusetts Institute of Technology (MIT) back in the 1980s. It’s named after the three-headed dog from Greek Mythology, Cerberus, who guards the gates of hell and keeps the dead from escaping. As a protocol involved in controlling access to systems, the name is fairly apt, although perhaps a little over-dramatic.
We currently use the fifth version of the Kerberos protocol to provide authentication for both clients and servers. It involves a third-party entity known as the key distribution center (KDC), through which all clients and servers are registered. The KDC uses cryptography to authenticate the parties to each other, and it also maintains the keys of all of the members on its network.
The KDC’s functions are comprised of:
- A ticket-granting service
- An authentication service
The Kerberos protocol is often involved in single sign-on. Kerberos negotiations by Jeran Renz licensed under CC BY-SA 4.0.
Both of these are generally hosted on the Kerberos authentication server, which is often referred to as the KDC itself. However, it is possible for the ticket-granting service to be hosted on another server.
To simplify how Kerberos works, first, the client must authenticate itself to the authentication server with their username and password. The client is then issued a secret key by the KDC, which is encrypted alongside a hash of the user’s password. The KDC also creates a time-stamped ticket-granting ticket, and sends both of these to the client. The client decrypts the symmetric key and installs the ticket-granting ticket, which it can then use until it expires.
Now that the KDC and the client have established the necessary details to form secure connections, the client can request a ticket from the Kerberos server whenever it wants to access a protected resource. It does this by sending its ticket-granting ticket alongside the request to the Kerberos server.
The KDC then verifies the ticket and whether the request is valid. If everything is valid, it then responds to the client by sending it a service ticket. The client can then send this service ticket to the service server, which is the server that hosts the protected resource that the client wants to access. The service server then takes the client’s ticket back to the KDC to have it verified. If everything is valid, the service server then sends through the protected resource to the client.
Kerberos is a little complicated for such a brief and simplified explanation, but the important takeaway is that the ticketing system gives Kerberos single sign-on functionality. The client only has to enter their username and password once, and then the tickets allow them to access multiple separate services without having to repeatedly authenticate themselves.
Security Assertion Markup Language (SAML)
When organizations wanted to implement single sign-on across a federation, they were met with some complex technical challenges. Organizations tend to develop their platforms independently, which means that their underlying infrastructure may not be compatible with that of the other organizations that they want to include in their federation.
Federations needed an open standard that each of these disparate organizations could agree on. They needed something that they could all use and mutually understand in order to manage user identities between themselves and exchange the relevant authentication and authorization information.
The Security Assertion Markup Language (SAML) was one of the early frameworks for achieving this. It traces its origins back to a 2001 meeting of the XML-based Security Services Technical Committee, which is a sub branch of the Organization for the Advancement of Structured Information Standards (OASIS).
In the minutes of the meeting, the committee clearly stated its aims:
“The purpose of the XML-Based Security Services TC [Technical Committee] is to define an XML framework for exchanging authentication and authorization information.”
The committee began its work using some earlier specifications and languages from contributing organizations. By 2002, they announced version 1.0 of the Security Assertion Markup Language (SAML) as an OASIS standard. An upgrade came in the form of version 1.1 in 2003. In 2005, SAML 2.0 was released, which was a convergence of the earlier SAML work plus the Liberty Alliance’s Identity Federation Framework (ID-FF).
The ID-FF was a framework with a very similar vision to SAML. Both sought to develop exchangeable mechanisms for authentication and authorization between organizations. It was developed by the Liberty Alliance, which was a consortium that included some of the biggest names in tech of its day, such as AOL, Sun Microsystems and HP.
SAML 2.0 is still the version in use today, and it’s an XML-based language that gives organizations a compatible way to exchange authentication and authorization information. It helps to facilitate single sign-on through web browsers, and allows users to access resources from other organizations in the federation, even though they are located in separate security domains.
SAML revolves around assertions and the trust relationships between parties within a federation. From the user’s perspective, SAML allows them to log in to Website A and then be directed over to Website B, another partner in the same federation.
Because website A has already authenticated the user and the two websites use SAML to share identities, the user does not have to reauthenticate themselves to access privileged parts of Website B. Using SAML terms for our example, Website A would be the identity provider, while Website B would be the service provider. Because the service provider trusts the identity provider and the authentication it has performed, the service provider doesn’t need to reauthenticate the user.
OAuth 2.0 and OpenID Connect
OAuth 2.0 is primarily a protocol for delegated authorization, while OpenID Connect is an authentication layer built on top of it. Earlier versions of each protocol first emerged in the mid-2000s and were a little different. These two iterations complement each other and are often implemented together to provide authorization and authentication in a federated identity management scheme.
While OpenID Connect runs over OAuth 2.0, the two play different roles. OpenID Connect is responsible for authenticating and managing the identities of users.
It allows a user to authenticate themselves to multiple services across different security domains, meaning that it can be used to manage their identity between organizations in a federation. If a user has authenticated themselves to one organization within the federation, they do not have to reauthenticate themselves to the other parties.
OAuth 2.0 is concerned with authorization and granting users access to resources. It’s often working under the hood when you see a popup that says something along the lines of:
“App XYZ would like to access your profile information. Would you like to grant it access?”
It facilitates the sharing of data and other resources between different services, such as by allowing Uber to access some of your information from Facebook.
While this may seem like a scary example with significant privacy ramifications, OAuth 2.0 allows you to control and limit access along pre-specified boundaries. However, you do need to read the fine print.
In our interconnected world where we need to constantly share data between apps to automate our workflows and streamline services, OAuth 2.0 allows us to do this without having to constantly authenticate ourselves and authorize access every single time that the apps talk to each other.
While the two standards can be deployed independently in certain situations, the fact that OpenID Connect is designed over the top of OAuth 2.0 makes them an excellent solution in circumstances where both authorization and authentication are required.
Is single sign-on safe?
Like many questions in cybersecurity, the answer isn’t so simple. We have already outlined how single sign-on includes both security pros and cons, with the major points on each side being that it can reduce password fatigue, but it also creates centralized systems with single points of failure.
There are trade-offs involved in single sign-on, but when we also consider the practical benefits from a user’s perspective, it’s hard to consider single sign-on as an overall negative development in our tech landscape.
Instead, it’s probably best to recognize that it’s the direction that the industry is heading in, and that it does make our lives a whole lot easier. However, the implementers and users of single sign-on need to be aware of the trade-offs that they are making, and take steps to mitigate the risks.
Due to the centralized nature of single sign-on, it can effectively give attackers the keys to the castle when they compromise an account. It’s important that we deploy more stringent security controls, such as multi-factor authentication.
It’s also worth remembering that single sign-on isn’t a monolith, and that it can be accomplished with a range of different technologies, some of which we haven’t had a chance to mention in this article.
Which technology an organization chooses will depend on its individual circumstances. If it’s just for within the premises, an old LDAP-based solution may be more than enough.
In other situations, the right choices might involve a combination of OAuth 2.0 and OpenID Connect. No matter which choice a company ultimately settles on, it’s critical that they evaluate their options and find the best solution for their unique scenario. It’s also important to consider the security weaknesses of that specific solution, and to come up with ways to help limit the risks that could emanate from a given implementation.